deno: Why is "moduleResolution" an ignored runtime option for Typescript?
“moduleResolution” is listed as an ignored compiler option, but why is this necessary? Ie. why does it fall under…
there are lots of parts of a TypeScript configuration file that are meaningless in a Deno context or would cause Deno to not function properly if they were applied.
… from https://deno.land/manual/typescript/configuration#how-deno-uses-a-configuration-file
compilerOptions.moduleResolution is meaningful (as it relates to loading third-party code) but I fail to see how it causes Deno to function improperly.
Typescript itself says that the “classic” strategy (which is what Deno uses) should only exist for backwards-compatability which means that a lot of projects written in Typescript are bound to use Node’s strategy where importing a directory will look (by default) for an index.ts file.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19 (4 by maintainers)
Nope, preventing the user from opting back into tsc module resolution is
entirelytechnical.You repeatedly made assertions (not inquiries) about how the hurdle isn’t technical and that it should be easy, after having been told otherwise. The question was “why don’t you do it, considering this?”.
Did you read the sentence you quoted from the manual?
I did say “it is fundamentally incompatible with Deno” in the 3rd comment on this issue. I think that is a pretty technical reason.
See, these are technical reasons, and it’s what I was asking for in the first place. Thank you for explaining.
There was never a mention that it wasn’t technically possible, just that it was an ignored compiler option. I asked why, and it took a few rounds of back and forth. It was not about “dislike”, it was about asking why the Typescript option was disabled. When I said “I fail to see how it causes Deno to function improperly” you could have simply responded with all of this in the first place rather than a positional statement about “where Deno aligns with”.
Statements like this aren’t helpful, and they don’t encourage people to use your tools. I don’t know if you intended any attitude with it, but it doesn’t read well over text.
It is not. Our TS host implementation (the thing typescript uses to get files from disk), is not capable of node style resolving. Enabling it would not “just work”.
Just FYI, the Node module resolution algorithm described in https://www.typescriptlang.org/docs/handbook/module-resolution.html#how-nodejs-resolves-modules which TS’s outdated and unfortunate resolution tries to mimic is something Node explicitly decided not to allow in its ESM loader. Try it. The broad community is actively trying to move away from this. Even if it is strictly an ideological desire which again it isn’t.
Because it is fundamentally incompatible with Deno. Module resolution in Deno aligns to how it works in the browser, not to Node or TSC.
Deno does not use the “classic” strategy described in https://www.typescriptlang.org/docs/handbook/module-resolution.html#classic. It uses browser-like ESM module resolution, which doesn’t involve guessing and trying to fetch multiple URLs for one module specifier.