Repository navigation
import.meta.resolve is not shimmed when using --rewriteRelativeImportExtensions #61541
Closed as not planned
Description
🔎 Search Terms
"rewriteRelativeImportExtensions", "import.meta.resolve", "require.resolve", "shim", "experimental-strip-types", "experimental-transform-types"
🕗 Version & Regression Information
- This changed in commit or PR Rewrite relative import extensions with flag #59767
⏯ Playground Link
No response
💻 Code
// tsc --rewriteRelativeImportExtensions
import("./foo.ts")
import.meta.resolve("./foo.ts")
// output:
import("./foo.js")
import.meta.resolve("./foo.ts")🙁 Actual behavior
While imports are correctly rewritten/shimmed, calls to import.meta.resolve/require.resolve are not impacted.
🙂 Expected behavior
I would expect import.meta.resolve to resolve to the same path as an import call, as per MDN Documentation.
Additional information about the issue
No response
Activity
RyanCavanaugh commentedon Apr 8, 2025
We have to draw some line where
import("x.ts")is rewritten andfs.readFile("x.ts")isn't.import.meta.resolveseems closer to the latter than the former, especially because it's legal to do something likewhich we don't have any chance of catching.
nwidynski commentedon Apr 8, 2025
Ryan Cavanaugh (@RyanCavanaugh) Hm, I haven't thought of
import.metabeing assigned to a new member, so thanks for the insight 👍That being said, I'm not sure I agree with
import.meta.resolvebeing closer tofs.readFile("x.ts")thanimport("x.ts"), since its explicitly documented to be corresponding:This behavior is broken when the
--rewriteRelativeImportExtensionssetting is enabled. A practical use-case where this becomes an issue is trying to spawn aWorkerwith a.tsfilename. Afaik, Node.js does not offer module resolution like typescript, where it's okay to import a.tsfile by its.jsextension. I was hoping to get this resolved through this issue.While not pretty, the
import.meta.resolvecould be shimmed itself instead of at the callsite:Jamesernator commentedon Apr 10, 2025
Worth noting there is a stage 2.7 proposal that allows for statically refering to modules for basically this exact usage.
RyanCavanaugh commentedon Apr 10, 2025
I mean, the best we can do is make this differently inconsistent, and I'm not seeing a case for why the proposed inconsistency is better than the existing one. The rules today are at least 100% syntactic; you can be sure that if you write
import("it's rewritten, but otherwise isn't. If the rule is any more complicated than that, you can't really predict ifis rewritten or not.
Having the rule be simple is super critical for single-file transpilers wanting to replicate TypeScript's behavior, since they don't have the same symbol resolution mechanics that TS does which would allow it to even realize that
import.meta.resolveis being referenced according to exactly some specific set of rules.We also need to consider the case where a runtime adds something like
import.meta.resolveCachedor something;resolveis "just a function" from TypeScript's perspective and it doesn't know that it deserves special treatment.typescript-bot commentedon Apr 13, 2025
This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
darksabrefr commentedon Jun 11, 2025
It could be handled, like other edge cases, by this proposal: #61050