gulp-tsb icon indicating copy to clipboard operation
gulp-tsb copied to clipboard

Confusion between libraries and local files

Open rigdern opened this issue 7 years ago • 3 comments

gulp-tsb matched my require to the wrong file. I had an import:

import Localizer = require('localizer');

gulp-tsb matched this to a file in the same directory, Localizer.ts, instead of to the localizer library which is in the node_modules folder.

I debugged it and identified this logic as being problematic.

Is there a reason that logic was written instead of calling ts.resolveModuleName? Maybe ts.resolveModuleName didn't exist when gulp-tsb was written (Microsoft/TypeScript#1793)?

rigdern avatar Aug 10 '17 23:08 rigdern

There is an option in the TypeScript configuration to case-sensitive or not. What is your configuration? Please share it here?

jrieken avatar Aug 14 '17 08:08 jrieken

@jrieken Here are the TypeScript compiler options I'm using:

{
    declaration: false,
    noResolve: false,
    jsx: 'react',
    reactNamespace: 'RX',
    module: 'commonjs',
    target: 'es5',
    experimentalDecorators: true,
    noImplicitAny: true,
    noImplicitReturns: true,
    noImplicitThis: true,
    noUnusedLocals: true,
    strictNullChecks: false,
    forceConsistentCasingInFileNames: true,
    typeRoots: [
        "node_modules/@types"
    ]
}

However, I think the casing confusion is irrelevant and the real issue is about the module resolution logic being incorrect (I linked to the particular logic in the original issue description). There are a couple of things that I think are incorrect about it:

  • If you use the notation for requiring a library (e.g. require('localizer')), gulp-tsb will resolve this to a file named localizer.ts in the same directory (if it exists) whereas the TypeScript compiler would never do that. If you want to match a file in the same directory, the TypeScript compiler forces you to use this notation: require('./localizer.ts').
  • The logic seems to ignore .tsx files. It only explicitly looks for .ts and .d.ts files.

I suspect we can fix these issues by replacing this custom resolution logic with a call to ts.resolveModuleName.

rigdern avatar Aug 14 '17 09:08 rigdern

If you use the notation for requiring a library (e.g. require('localizer')), gulp-tsb will resolve this to a file named

Unsure, the code you are referring to is building a graph that is used a reverse lookup when a file changes. While that now contains invalid/missing information it shouldn't affect the outcome of the first compile run but is error prone in the re-compile strategy when one of the files changed.

The logic seems to ignore .tsx files. It only explicitly lo

That is correct, but again it's just for the dependency graph

I suspect we can fix these issues by replacing this custom resolution logic with a call to ts.resolveModuleName.

That might be. Can you give it a try?

jrieken avatar Aug 14 '17 09:08 jrieken