Add rewriteImportExtensions option to TS preset

[nicolo-ribaudo]

Q	A
Fixed Issues?	Fixes #1, Fixes #2
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link	babel/website#2825
Any Dependency Changes?
License	MIT

This PR moves the plugin introduced in #15892 to the TS preset, so that our users can use it too (rather than keeping it just for ourselves :P).

How do you feel about doing this? Technically it's a divergence from tsc (which never rewrites imports), but it's opt-in behind an option.

It's a quite popular TS feature request (microsoft/TypeScript#55346, microsoft/TypeScript#49083, microsoft/TypeScript#37582, and many others), and now that TS provides the allowImportingTsExtensions option we are in a position of allowing it.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/55407/

[bakkot]

Yes please! I understand Typescript's reasoning for not doing this, but I think they're wrong. I really would like to be able to tell users to do the obvious thing instead of something which feels like a dumb hack.

Do note that there's some edge cases here - in particular, this will break if the user is importing (and not bundling) a package whose name ends in .ts, like this one.

[liuxingbaoyu]

Good idea.
Since #15913 (comment), is it possible for us to use if(source?.startsWith("."))?

[JLHwung]

Suggested change

	source.value = source.value.replace(/(\.[mc]?)ts$/, "$1js");
	source.value = source.value.replace(/(\/.+?\.[mc]?)ts$/, "$1js");

To cover the edge case mentioned by @bakkot, unless the import is specified as import "/tmp/soundcloud.ts", which we can't tackle without resolving it first.

[liuxingbaoyu]

if (!source.includes("@"))

We may also want to exclude @, such as @org/mod.ts.

[nicolo-ribaudo]

I would only special-case import specifiers that contain no \ or /, because the only way a specifier without / could work is if it maps to a folder (using Node.js' resolution algorithm) or to a file without any rewriting (using an import map).

For example, I have a project with an import map that includes the following:

{
  "imports": {
    "@/": "./",
    "@components/": "./frontend/components/"

As such, @/foo.ts and @components/foo.ts both map to files and not to directories (and thus they would need their .ts extension to be rewritten).

I would prefer to either (in other of preference):

1. do nothing, and if somebody has some imports that must not be rewritten they can disable the option for that file
2. only ignore imports with no /
3. extract the plugin to its own package, and when it's used directly allow passing a function originalSpecifier => transformedSpecifier to allow users to filter and transform however they want

However, before doing (3) I would wait for someone to open an issue with a concrete use case.

[liuxingbaoyu]

extract the plugin to its own package, and when it's used directly allow passing a function originalSpecifier => transformedSpecifier to allow users to filter and transform however they want

We can even allow rewriteImportExtensions to pass in a function in the future.😉

[JLHwung]

We can also early return if importKind is type, since they will be stripped by the typescript transform anyway.

[JLHwung]

Pending Babel 8 snapshot updates.