-
Mainly what the title says. What I would like to solve, is to have package related type aliases that can be used inside the package only, but still keep go-to definition, and type inference in Visual Studio Code. I know, that tsconfigs extends, is not really an extend, more like an overwrite, so that to keep all path aliases, I should copy-paste them inside the packages tsconfig.json, but even if I do this, and add some additional package related aliases, VS Code doesn't like them. For example, let's say, I've added the type alias
If I then try to import this in to I've also tried to use Any ideas on how this can be solved? |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
Hey @ekr3peeK, have you checked out the CRA example? It uses internal aliases, and like you already figured out, has to duplicate the "main" monorepo aliases.
That would be correct. What happens is the internal alias cannot be resolved when compiling the consuming package, so a compilation error is raised. The language server will report If you want internal aliases to work you have to duplicate them in the consuming packages as well. Alternatively, if you're willing to degrade the DX a bit (no hot reloads for instance), you can build the package that uses internal aliases with something that rewrites the imports (e.g. babel) before consuming it in other packages. |
Beta Was this translation helpful? Give feedback.
-
In the meantime, I found another solution for these internal aliases (however still wasn't able to resolve the solution of having to retype the main aliases from the main tsconfig.json) - if you set up project references in typescript, internal aliases are also resolved and followed, and the IDE (at least VSCode, which I use), correctly identifies the types that are being used. Now another problem what I am facing, is that in the past (before attempting to migrate to a monorepo from a monolith), we used
As a side-note, I really like the benefits a monorepo would give us, but I am totally amazed on how underdocumented this section is - just to setup a basic monorepo project, I navigated around ~100 different websites, all givin half-solutions to problems, which I do not think are that uncommon. In the "monorepoverse", normally during development, what would be the best practice? To rebuild every package on file change, and run the dev scripts on the built packages, or something what I would want to achieve, to run dev scripts on uncompiled ts files for examples? And I am still yet to set-up jest for this monorepo project, I can only wonder what kind of caveats will I find while I am doing this:P |
Beta Was this translation helpful? Give feedback.
-
Yes, project references automatically build dependent projects. When I first started this template, this only worked at build time and didn't work with "live" code. I'll have to check them again to see if they improved this.
That's actually a very common setup. You might want to try https://www.npmjs.com/package/ts-node-dev, it should automatically reload on changes to dependencies.
I tend to prefer running hot reload centric tools (ts-node-dev, webpack etc.) to compile projects and all their dependencies in one go, but of course this has some disadvantages:
For small to medium teams, where it's easy to keep configs and TypeScript versions in sync, I recommend the approach above. For cases where changes to shared packages happen infrequently, or where the shared packages need different configs, then it could make more sense to use project references, or straight up pre-building the packages.
Make sure to check the jest example 😄 |
Beta Was this translation helpful? Give feedback.
-
I will sure do! Thanks again for this repo, after browsing a lot, and trying out different things, in the end, this was the one that put me on the right track to achieve what I was aiming for with the monorepo! |
Beta Was this translation helpful? Give feedback.
-
Pasting from #348:
Please look at the existing example in apps/cra which defines a local alias. I've also created a proof of concept here for using a local alias inside |
Beta Was this translation helpful? Give feedback.
Pasting from #348:
Please look at the existing example in apps/cra which defines a local alias. I've also created a proof of concept here for using a local alias inside