11 ms·
Browsers never required extensions, see https://unpkg.com/ https://unpkg.com/ You can load scripts in browser just fine without extension. > Now, that does no
by Chyzwar 4y ago
Browsers never required extensions, see https://unpkg.com/ https://unpkg.com/
You can load scripts in browser just fine without extension.
> Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node.
I think they should provide a better explainer. But node.js resolution algorithms is already incredibly complicated, and adding path rewriting to typescript is not going to make it better. There are things like dynamic import and third part libraries. Typescript would need to either analyze whole of project node_modules or bundle custom runtime resolver like webpack breaking compact with deno and friends.
Imagine situation:
import lib from 'somelib/subpath'
How TS would know that some lib have extension in subpath and it need to add/remove js ext? https://nodejs.org/api/packages.html#extensions-in-subpaths https://nodejs.org/api/packages.html#extensions-in-subpaths
What if typescript is running in deno/bum or wasm?
> Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem.
My conclusion is that successful projects without BDFL are prone to corporate takeovers. You have people that working in corporations without writing code and want to make political career as "core" team member of project.
- zarzavat 4y agoTS 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.