Description Extension Rewriting
#59767
We've discussed what we need to do with async imports.
One possibility: you do the transform yourself.
Another: we provide a runtime shim - possibly overridable.
Also: we have the same situation for require calls in JS input files.
It is currently not as common, but possible, for us to transform JavaScript input files.
Those files can still refer to .ts files - do we want rewriting for those?
Does the experimental mode in Node support require?
There's require with a plain string and an arbitrary expression.
Why do we care about this difference?
require can be passed into arbitrary places.
Makes us inclined to say no shimming.
We could error on require of an arbitrary expression in this mode.
People can always alias require or // @ts-ignore.
Extension rewriting was always weird - but if we're gonna do it, maybe we should do it in a maximalist way?
Feels like if semantics diverges between runtime and emit, that's a problem.
Could just say only require on static imports.
Can you just create arbitrary requires?
Yes, there's createRequire - could maybe monkey-patch this?
Also require.call(...)
Could add an import attribute to turn off rewriting for import().
Moved from "don't shim anything" to "shim everything".
Between import attributes and (require)(...) these are reasonable opt-outs.
Also open to just a global flag...
Or a third state for the flag.
"none", "staticImportsOnly", "bestEffort"?
Reactions are currently unavailable
You can’t perform that action at this time.
Extension Rewriting
#59767
requirecalls in JS input files..tsfiles - do we want rewriting for those?require?requirewith a plain string and an arbitrary expression.requirecan be passed into arbitrary places.requireof an arbitrary expression in this mode.requireor// @ts-ignore.requireon static imports.requires?createRequire- could maybe monkey-patch this?require.call(...)import().(require)(...)these are reasonable opt-outs."none","staticImportsOnly","bestEffort"?