Bug With Symlinked Packages in Monorepo

Bug report

I’m using dts-bundle-generator in my experimental monorepo. I found it irreplaceable, especially if I bundle in some of my devDependencies and they would not exist as packages in published npm package, but their TypeScript declarations need to be inlined. I don’t know any other tool that does this. Well done 👍. And thank you 🙏.

I use pnpm to install packages. So I have following directory structure which describes pnpm behaviour the best:

packages/
  packageA
    node_modules
      packageB -> ../../../packageB
    *.ts
  packageB
    *.ts

We can see that packageB is going to be a symbolic link.

When using dts-bundle-generator I get a compiler error, saying that I cannot import this or that. Example:

Additional context

The test that reproduces this issue is here: https://github.com/zaripych/dts-bundle-generator/commit/49ad3a6d1035bc790268f55d048ec89fb44382f0

I fixed it by making these changes: https://github.com/zaripych/dts-bundle-generator/commit/794a1a3c38135ec65c27e3c6e6a6604135ae1981#diff-5a014ac4d87f713ea8b9c8dd8966ce3b77df4ecc8e263b4baf9b9469bf9f2917

Would it be possible to incorporate these changes in the main repo?

[timocov]

it’s how dts-bundle-generator setups it internally. If you try to run tsc --build tsconfig.json in the packages/tooling-tests/todo-list-cli - it works without errors. The only difference is that composite: false for the generator …

Because it switches the compiler to another way of working, which is a build mode or know as composite projects (or referenced projects) that aren’t supported right now (see #93).

[timocov]

Ok I was able to run this on wsl, here is my observations:

• by default (if you don’t change the config file) you get bunch errors like error TS2307: Cannot find module or its corresponding type declarations., by digging into the issue I found out that this is the behaviour of the compiler - it treats files in node_modules as something that shouldn’t have an emit so it doesn’t generate any output for them (that’s what we’ve discussed above, I agree with the compiler and having a code that handles this correctly is kind of strange and I wouldn’t like to do this). Even though I don’t quite understand why these files are treated as files from node_modules, I’d expect them to be treated as local ones, because after resolve they don’t have node_modules in their paths. But I think this is the questions to the compiler team:

• if you add followSymlinks: false to the config, then it warns with… the same issue actually but different errors - now the tool complains about files that are in the compilation but they are not d.ts ones. But later the building ended with an error Error: Cannot find symbol for node: Plugin. After debugging this problem I figured out, that for some reason the compiler decides to load types for jest package and it causes this error (it comes directly from its types). If you add "types": ["node"], to tsconfig for the tool the problem goes away. But then of course the compilation fails because in the declaration bundle it finds something that shouldn’t be there, for example a function’s body, and it comes directly from the warning.

So I’d say probably the best solution here is to use paths. Alternatively you can ask the compiler team why the compiler doesn’t generate an output for files that were resolved from node_modules to a local folder (outside of node_modules; so basically the case is the following: node_modules/@internal-package/src/index.ts -> ../internal-package/src/index.ts, but the compiler treats this file as “comes from node_modules” and doesn’t generate an output for it).

Another solution could be set up the right order of building packages and compile them first and then bundle the declarations.