gulp-tsb
gulp-tsb copied to clipboard
Confusion between libraries and local files
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)?
There is an option in the TypeScript configuration to case-sensitive or not. What is your configuration? Please share it here?
@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 namedlocalizer.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
.
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?