Using a library that has both ts and d.ts files in the same folder causes issues

[ronzeidman]

TypeScript Version: all

Code
importing files, for example

import 'reflect-metadata/Reflect.js';

causes the following exception in tsc:

error TS6059: File 'client/node_modules/reflect-metadata/Reflect.ts' is not under 'rootDir'
 'client/src'. 'rootDir' is expected to contain all source files.

the tsconfig.json looks like this:

{
    "compilerOptions": {
        "declaration": false,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "module": "commonjs",
        "moduleResolution": "node",
        "noEmitOnError": true,
        "noImplicitAny": false,
        "rootDir": "./src",
        "sourceMap": true,
        "target": "es5",
        "outDir": "dist/"
    },
    "files": [
        "src/bootstrap.ts"
    ]
}

Expected behavior:
Suggestions:

1. don't try to recompile .ts files not under rootDir if there is a js file there (if there isn't throw the same exception)
2. don't try to recompile .ts files under node_modules folder unless there is no js file there
3. don't compile excluded files even if referenced (that way you can use both "files" and "excluded" in the tsconfig.
4. some configuration like compileDependencies: 'true'/['specific-dependency1', 'dep2']/false
   Actual behavior:
   tries to recompile everything even if it's from node_modules folder and even if I don't directly reference the .ts file and reference the .js file instead
   workaround 1: reference the.d.ts file instead of the .js file (doesn't work if the module itself has dependencies)
   workaround 2: put the .ts and the .d.ts+.js files in a different folder in the library but it's not possible for existing libraries since they are provided by a third party.

[mhegazy]

why not just import "refelect-metadata";? the pacakge.json for the package specifies the .d.ts file, when you pick a specific file (i.e. Reflect.js) this option is not honored, and the normal resolution mechanism takes precedence, and the .ts file is always preferred.

[ronzeidman]

In this case it's true (once upon a time it didn't work and the import remained like that), but if you have a library that has "imports" in the main d.ts file and it imports something else the .ts will take precedence instead of the .d.ts/.js

for example: https://github.com/ronzeidman/open-ng2-tests
This uses https://github.com/PointInside/ng2-toastr which has in it's package.json

  "main": "ng2-toastr.js",
  "typings": "ng2-toastr.d.ts",

but the main file looks like this:

export * from './src/toast';
export * from './src/toast-manager';
export * from './src/toast-container.component';
export * from './src/toast-options';
export * from './src/toast.module';

There are 4 files called ./src/toast -> ./src/toast.ts, ./src/toast.d.ts, ./src/toast.js. ./src/toast.js.map and the one that gets resolved is always the .ts file.

There is an issue about it: https://github.com/PointInside/ng2-toastr/issues/35 but I had other libraries that have the same issues like https://github.com/kamilkp/ng2-vs-for
I know they are small libraries and keeping sources and compiled output in the same folder is not the best practice but it's the default one, and I don't see why it shouldn't work.

[mhegazy]

when resolving a.js the same logic is followed to resolve a. The resolution process always favors the .ts files over .d.ts. the rational here is that a .d.ts file can be generated from the .ts file, so the .ts file is a more up-to-date version of the truth.

We did in the past give .d.ts higher precedence in importing, and that broke scenarios for npm-link for example, where you really want to import the .ts and not the .d.ts as you are developing multiple npm modules that depend on each other.

the solution here is to either use the module name, e.g. "ng2-toastr", or make sure your .ts files are not generated at the same location. you can achieve the later by having a src\ts folder and build using --outDir <outputLocation>. hope that helps.

[ronzeidman]

OK, thanks for explaining. I'll refer the other library owners to this thread.

[wclr]

I too encountered a problem with this this. Generally my case: I have a TS monorepo with multiple independent packages (that are published seperatly, so the TS code and JS generated code should be nearby inside particular package).

Packages share the same TS configuration, so it is quite reasonable I believe to build everything at once in one tsc scope/process. As TSC yet doen't support building multiple projects within one process, I just should start it in the root. And I can not build all files in a separate outDir (I can ofc ource implement it) then I would need to move sources around before publishing (though I'm not sure what will be with source maps)... So this is not nice, I should use it without outDir, it is actually ok just to have built JS version near the TS source (JS may be concealed using IDE settings not to mess with them visually).

But the problem is that dev TS source code may have some types imports that are supposed to be used only to help while development, they are not exported and not supposed to be used by package user, so that my-package-module.ts may use some typing's from @types/dev-only-dependency, but my-package-module.d.ts wouldn't have a mention of it. So if Typescript takes .ts sources it would require user project to have this @types/dev-only-dependency installed though if I would take .d.ts it wouldn't though would work the same way.

when resolving a.js the same logic is followed to resolve a. The resolution process always favors the .ts files over .d.ts. the rational here is that a .d.ts file can be generated from the .ts file, so the .ts file is a more up-to-date version of the truth.

We did in the past give .d.ts higher precedence in importing, and that broke scenarios for npm-link for example, where you really want to import the .ts and not the .d.ts as you are developing multiple npm modules that depend on each other.

I think I fail to fully understand a logic behind those decision (of changing priority from d.ts -> ts). If you create a package that puts d.ts along with corresponding .ts then what is the purpose of d.ts? It will never be used any way and .ts version will be used by compiler instead. The only reason if you are not going to publish ts sources? Well then one probably should make his workflow more appropriate (create .d.ts just while publishing step, and then remove it while development). In my view it is more logically correct to give .d.ts higher precedence in importing and making the swap was kind of plugging a hole without good thinking of the possible consistences. Maybe I'm missing something?

@mhegazy what do you think about it?

[wclr]

@mhegazy have you read my thoughts why I think that d.ts should have priority on .ts source?

[mhegazy]

I think I fail to fully understand a logic behind those decision (of changing priority from d.ts -> ts). If you create a package that puts d.ts along with corresponding .ts then what is the purpose of d.ts? It will never be used any way and .ts version will be used by compiler instead.

if you are developing the app, and your .ts and .d.ts are generated side by side (which is the default of the compiler) you want the .ts to be picked first.

In my view it is more logically correct to give .d.ts higher precedence in importing and making the swap was kind of plugging a hole without good thinking of the possible consistences. Maybe I'm missing something?

if the two files represent the same module, then the .ts is more accurate as it is the source. if they do not represent the same module, they should not live side by side in the same folder.

[wclr]

if you are developing the app, and your .ts and .d.ts are generated side by side (which is the default of the compiler) you want the .ts to be picked first.

If .ts is still picked first, generating corresponding .d.ts along with it doesn't make sense at all in this case, no?

[wclr]

@mhegazy ?