2 ms·

TS can already perform complicated refactorings, such as renaming all imports in a project when you rename a file in vscode. So they definitely have all the inf

TS can already perform complicated refactorings, such as renaming all imports in a project when you rename a file in vscode. So they definitely have all the information they need already. Node requiring the .js is more understandable, as that actually affects runtime performance: if the name isn’t fully qualified in source then node needs to stat() more paths during resolution. > What if typescript is running in deno/bum or wasm? Every TS project already needs a tsconfig.json to specify what permutation of module system configurations it is using.

Chyzwar 4y ago
> Node requiring the .js is more understandable, as that actually affects runtime performance: if the name isn’t fully qualified in source then node needs to stat() more paths during resolution. Performance is affected only during startup by maybe few milliseconds. This is a major breaking change to module resolution made by node.js. Why TS should paper over change that was made by node.js. > TS can already perform complicated refactorings, such as renaming all imports in a project when you rename a file in vscode. So they definitely have all the information they need already. Some things are supported by tsserver not typescript compiler. Fixing this in TS is only addressing the problem partially and is shifting the problem into tools developers.