`import.meta.resolve` is not shimmed when using `--rewriteRelativeImportExtensions`

[nwidynski]

🔎 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

[RyanCavanaugh]

We have to draw some line where import("x.ts") is rewritten and fs.readFile("x.ts") isn't. import.meta.resolve seems closer to the latter than the former, especially because it's legal to do something like

const foo: any = import.meta;
foo.resolve("x.ts")

which we don't have any chance of catching.

[nwidynski]

Ryan Cavanaugh (@RyanCavanaugh) Hm, I haven't thought of import.meta being assigned to a new member, so thanks for the insight 👍

That being said, I'm not sure I agree with import.meta.resolve being closer to fs.readFile("x.ts") than import("x.ts"), since its explicitly documented to be corresponding:

"[...] to the path that would be imported if the argument were passed to import()".

This behavior is broken when the --rewriteRelativeImportExtensions setting is enabled. A practical use-case where this becomes an issue is trying to spawn a Worker with a .ts filename. Afaik, Node.js does not offer module resolution like typescript, where it's okay to import a .ts file by its .js extension. I was hoping to get this resolved through this issue.

While not pretty, the import.meta.resolve could be shimmed itself instead of at the callsite:

const { resolve: r$182s9f } = import.meta;
import.meta.resolve = (path) => r$182s9f(path.replace('.ts', '.js'));

[Jamesernator]

A practical use-case where this becomes an issue is trying to spawn a Worker with a .ts filename.

Worth noting there is a stage 2.7 proposal that allows for statically refering to modules for basically this exact usage.

[RyanCavanaugh]

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 if

const { resolve } = import.meta;
resolve("path")

is 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.resolve is 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.resolveCached or something; resolve is "just a function" from TypeScript's perspective and it doesn't know that it deserves special treatment.

[typescript-bot]

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]

It could be handled, like other edge cases, by this proposal: #61050