I presume, using package relative type aliases in tsconfig is out of the question - would there be any way of solving this?

[ekr3peeK]

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 config for package-a, that points to an inner config folder, and my index.ts file looks something like this in package-a:

export config from 'config';

If I then try to import this in to app-a, type definitions for the config variable are completely lost. I presume this is happening because when I am browsing a file in app-a project, the tsconfig associated with that app does not know how to resolve the config keyword, and maps it to any instead.

I've also tried to use Node16 for module resolution, and rely for package related aliases on package.json imports, but that brings with itself a bunch of other problems.

Any ideas on how this can be solved?

[NiGhTTraX]

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.

when I am browsing a file in app-a project, the tsconfig associated with that app does not know how to resolve the config keyword, and maps it to any instead.

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 any to your IDE, while tsc will fail with that error. You can see what's happening under the hood by running tsc --noEmit --traceResolution.

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.

[ekr3peeK]

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 ts-node for development, together with nodemon to reload a backend script on a file change. There are two problems with this:

1. ts-node won't resolve the path aliases by itself, and even if we use something like tsconfig-paths, only the apps aliases will be resolved, and reference aliases are ignored - to solve this, I've "hacked" the tsconfig-paths (it exposes some useful functions that can be used), so that when a module is being resolved, it takes into consideration the import/requiring context, and uses the appropiate tsconfig.json to resolve the path aliases - for initial tests, this work, but I am yet to see it in action, in a proper, larger codebase
2. nodemon by default is only watching the working directory from where it was started, for file changes - you can add additional watch options when running it, but this would indicate, that each time I am adding a new package, that will become the dependency for an app for example, I would need to update the package.json in the app, to tell nodemon to also watch this package for file changes, and it seems a bit tedious for me - what I am experimenting with at the moment, to basically when developing, bundle the backend code with webpack, and set up a watch to rebundle on a file change, and then set up nodemon, to run the bundled file, and watch ONLY the bundled file, and restart it as soon as webpack rebundles it in watch mode - does this sound totally insane, or would you think this would work?

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

[NiGhTTraX]

if you set up project references in typescript, internal aliases are also resolved and followed

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.

[...] does this sound totally insane, or would you think this would work?

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.

[...] what would be the best practice?

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:

• it will compile the dependencies every time, unless incremental builds are used (not supported by all toolchains),
• leaks aliases from dependencies to consumers,
• does not allow different configs for dependencies, as they will be compiled with the project's config.

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.

And I am still yet to set-up jest for this monorepo project

Make sure to check the jest example 😄

[ekr3peeK]

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!