Need warn about ts files (not dts) in compilation from node_modules

I would like to include the typings for https://github.com/Lusito/typed-signals in my DTS bundle, however the extraction fails with “Error: Cannot find symbol for node: emitCollecting”.

app.ts:

import {Signal} from "typed-signals";

export const signal: Signal<(argument) => void> = undefined;

package.json:

{
  "name": "dts-bundle-generator-bugreport",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "build": "npx tsc",
    "typings": "npx dts-bundle-generator -o app.d.ts app.ts"
  },
  "dependencies": {
    "typed-signals": "^1.0.2"
  },
  "devDependencies": {
    "dts-bundle-generator": "^1.6.1",
    "typescript": "^3.1.3"
  }
}

tsconfig.json:

{
  "compilerOptions": {
    "target": "es5",
    "declaration": true,
    "lib": ["es2015", "dom"]
  }
}

Run:

npm install
npm run typings

Output:

Error: Cannot find symbol for node: emitCollecting

The method looks like this (see https://github.com/Lusito/typed-signals/blob/master/src/Signal.ts):

export class Signal<CB extends Function> {
  // ...
  protected emitCollecting<RT>(collector: Collector<CB, RT>, args: any) {
    // ...
  }
}

[timocov]

I’m back after looong time 😃

because I build them all in parallel (which speeds up builds a ton).

Hm, it’s a little bit unexpected for me. I believe it speeds up builds, but it confuses.

Hmm, you could probably gather the import statements from the AST of each module

Yeah, I need. There is a lot of issues caused by that - https://github.com/timocov/dts-bundle-generator/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3Adetect-import-path-problem

I wouldn’t be able to build in parallel.

I believe in this case you need to have resolver/scheduler which will make a build plan and detect which packages can be built in parallel.

I just dig into

Notice how tsc doesn’t throw an error when a dependency’s main module isn’t compiled. I think dts-bundle-generator should work the same way

and it seems that there is no way to get dts file for module from node_modules directory. The compiler doesn’t provide a way to generate declaration file for any source file (like transpile or transpileModule to get JS output).

If you ignore that warning, does it work correct for you or you get some errors?

/cc @aleclarson

[timocov]

Notice how tsc doesn’t throw an error when a dependency’s main module isn’t compiled

I can’t imagine a case where it’s ok, even for monorepos, because it would be better to have compiled .d.ts files instead of .ts ones to avoid unnecessary compilation of source files which wouldn’t generate an output.

Also, I believe that in case of monorepo you need to compile dependencies first and generate .d.ts files for them (it’ll reduce a building time as well, because parsing .d.ts is easier than parsing and compiling .ts file).

Also that warning is about .ts files in node_modules folder, which (I believe) shouldn’t be even exist in common case of using npm/yarn (because a packages should provide declaration files, not source files as declaration ones).

By default, when dts-bundle-generator finds a symlink, it follows the symlink and includes its type definitions in the .d.ts bundle.

Not actually. Resolving symlinks are for the TypeScript compiler. After the compiler creates the program, dts-bundle-generator uses files it provides to work with them, and there is real paths, not import/require’s ones. For now dts-bundle-generator treats file as external by its path (so, if tsc resolves an import to original file located in the same folder - dts-bundle-generator will treat it as local one, not external; but if no symlinks resolving happened, then a file’s path will contain node_modules path and the tool will treat it as external).

Symlinks to external modules should be treated as if --disable-symlink-following was given.

How to detect that some module is external one? It looks like we have a path of the file only for that.