Typescript does not solve the modules correctly with dependencies in monorepo

[matuzalemsteles]

This bug sounds pretty familiar with what we had when we started building the components of Clay, so I'm going to leave a checklist of things that we should look out for to create an integration and not have any problems ahead. (I wait)

• The resolved module should not be duplicated, we will have more cases ahead, when we have cyclic dependency in some cases where the a package depends on the b and c package and the c package depends on the b package, we have to be careful that there is no duplication of code.
• The yarn start command that is running webpack should resolve the packages correctly and point to the tsx files. (Probably we'll have to make some modifications to make this happen, typescript is trying to solve the package.json main by picking lib/ClayXXX...)
• We must ensure that the main attribute of package.json is pointing to files compiled in the lib folder. (One solution is to modify the attribute to point to tsx files in development environment...)
• We have to make sure that the tests can resolve the dependencies correctly for the respective tsx files of each package.

[wincent]

Not sure if this is helpful, but when I rolled out Typescript in a monorepo I had to use the moduleNameMapper config option to get Jest to be able to resolve the packages, and the analog here would be something like:

    "moduleNameMapper": {
      "clay/(.+)$": "<rootDir>packages/$1/src"
    },

Not sure whether this is useful either, but I also note that here we have this in our "tsconfig.json":

	"include": ["packages"],

but I used:

  "include": ["packages/*/src/**/*.ts"]

[matuzalemsteles]

hey @wincent thanks for this, I'll test. Some of the problems we have is that the Typescript loader resolves only to the files declared in compiled main (See microsoft/TypeScript#21423). This testing paths with:

"paths": {
	"@clayui/*": ["node_modules/@clayui/*"],
}

A hack solution would be to change the main path to point to the src files in the development environment. (As long as we do not have the resolution of microsoft/TypeScript#21423).

Another solution is to change the path to point to src and add an index.ts to export the main files.

"paths": {
	"@clayui/*": ["node_modules/@clayui/*/src"],
}

But anyway, we will have issues with VSCode's Intellisense.

[matuzalemsteles]

I think the only temporary workaround for this to work fine is always to run yarn build from the package you depend on so the Typescript will pick up from the compiled, I tried to see other solutions but could not find one or to add the index.ts in the packages and point directly to the src. What do you think?

cc @bryceosterhaus

[bryceosterhaus]

Yeah the best solution I found was the run the lerna build command from the root and then sometimes I also needed to run yarn link for the required packages.

[wincent]

Another solution is to change the path to point to src and add an index.ts to export the main files.

That sounds pretty clean; what's the problem with doing it that way?

[matuzalemsteles]

hey @wincent I did not want to have to point to the src file directly, I just wanted to get the paths from package.json I think this is a bit hack, but maybe it's the best solution since we'll get the source and not compiled, a negative catch point of the compiled that we will always have to run yarn build to update the dependencies (this will become a little painful over time and as the dependencies of the larger components grow). What do you think @bryceosterhaus?

[bryceosterhaus]

Sorry, for some reason I am just seeing this now.

Another solution is to change the path to point to src and add an index.ts to export the main files.

"paths": {
  "@clayui/*": ["node_modules/@clayui/*/src"],
}

This seems like the best solution to me. I personally prefer "index" for entry points to the module as well, so it seems fine to me.

I am actually running into this issue with the storybook demos, I will add a commit with this for testing it out.

[matuzalemsteles]

ok, thanks @bryceosterhaus.

[matuzalemsteles]

Closing this, since we have resolved this through #1838.