Fix support for import/export in .cts files

[liuxingbaoyu]

Q	A
Fixed Issues?
Patch: Bug Fix?	?
Major: Breaking Change?	Probably not, but not 100%
Minor: New Feature?
Tests Added + Pass?	√
Documentation PR Link
Any Dependency Changes?	√
License	MIT

[liuxingbaoyu]

This is probably not good, since it means incompatibility with allExtensions. I want to know your opinion.

[nicolo-ribaudo]

Would updating this preset to only specify the unambiguous source type and keep the modules transform out of the preset work?

[liuxingbaoyu]

babel.config.cts requires it, and almost all cts files require this. Because when using require instead of import, tsc cannot get type information, even for built-in modules like fs.

[liuxingbaoyu]

Do we have any existing way to test @babel/preset-typescript in workspace? Now it loads plugins on npm forever.

[nicolo-ribaudo]

I think .cts files are supposed to be parsed as "unambiguous". If I try this CTS file:

export {};
with ({});

TS complains that with cannot be used in strict mode, so it's parsing it as a module.

[nicolo-ribaudo]

Do we have any existing way to test @babel/preset-typescript in workspace? Now it loads plugins on npm forever.

I usually copy-paste it outside of the repo (so that it doesn't actually build itself), and update package.json to use it from the local filesystem.

[babel-bot]

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

[nicolo-ribaudo]

I would describe previous versions 7.21.0 as "they supports cts files, but it has a bug that makes it not work with imports/exports". This would also avoid the breakage of throwing for whoever is already using babel.config.cts files with an older version of the preset (which works for all the simple self-contained configs)

[nicolo-ribaudo]

Why do we need this change?

[liuxingbaoyu]

Now sourceType must be one of the two, unless one uses babal-7-beta and writes a new bug to trigger this.

[liuxingbaoyu]

CI failures are related.
Do we need to fix @babel/preset-typescript for esm versions now? Or skip this test.

[nicolo-ribaudo]

Do we need to fix @babel/preset-typescript for esm versions now? Or skip this test.

.cts configs are already broken in Babel 8, because we already cannot synchronously load the preset, right? We can skip the test for now.

I'm still not convinced that enabling the CJS transform in the preset is a good idea, but I'm playing a bit with tsc to either:

• convince myself that it's ok to do it, or
• give a proper reason to why I think it's not a good idea.

[liuxingbaoyu]

microsoft/TypeScript#51479 (comment)

No transformations between module systems
True to its name, verbatimModuleSyntax has another consequence: ESM syntax cannot be used in files that will emit CommonJS syntax. For example:

import { writeFile } from "fs";
This import is legal under --module esnext, but an error in --module commonjs. (In node16 and nodenext, it depends on the file extension and/or the package.json "type" field.) If the file is determined to be a CommonJS module at emit by any of these settings, it must be written as

import fs = require("fs");
instead. Many users have the impression that this syntax is legacy or deprecated, but that’s not the case. It accurately reflects that the output will use a require statement, instead of obscuring the output behind layers of transformations and interop helpers. I think using this syntax is particularly valuable in .cts files under --module nodenext, because in Node’s module system, imports and requires have markedly different semantics, and actually writing out require helps you understand when and why you can’t require an ES module—it’s easier to lose track of this when your require is disguised as an ESM import in the source file.

That could be a reason, but this option doesn't seem to be used by many people.

[liuxingbaoyu]

CI is a regression of node v19.8.0.

[nicolo-ribaudo]

The result of my analysis with TSC is that there is absolutely no difference between .cts and .mts files:

1. even if they don't contain imports or exports, they are always parsed as modules (the output generated by tsc always sets __esModule)
2. the extension of the file has no effect on how modules are compiled:
   • both in .cts and .mts files, if you don't specify the "module" option (or if you specify "module": "CommonJS", which is the default value) you get a CommonJS output
   • both in .cts and .mts files, if you don't specify the "module": "ES2022" option you get an ESM output
3. regardless of how the module is transformed, .cts files are always converted to .cjs files (even if they might contain ESM statements) and .mts files are always converted to .mjs files (even if they might contain CJS statements)

TypeScript's "module": "ES****" option has always been equivalent to "don't compile modules with Babel" and its "module": "CommonJS" option has always been equivalent to "add @babel/plugin-transform-modules-commonjs, or make sure that @babel/preset-env is compiling to CommonJS". As such, I would still prefer to not include the CommonJS plugin in our TypeScript preset.

However, since users cannot change the config we use to load babel.config.cts files, I think we should include @babel/plugin-transform-modules-commonjs in @babel/core (maybe only if it's installed, similarly to how we are checking if the TS preset is installed?):

• if users do not need to use imports/exports in their TS Babel config, they will not notice any difference
• if they want to use imports/exports, they can do so by installing the plugin to compile them to CommonJS (or, we might just add it as a dependency of @babel/core and make it work by default maybe?)

[liuxingbaoyu]

3. regardless of how the module is transformed, .cts files are always converted to .cjs files (even if they might contain ESM statements)

This is really weird, I can't figure out what to do with .cjs with import.

if users do not need to use imports/exports in their TS Babel config, they will not notice any difference

This may be relatively rare, especially in babel.config.cts, only the configuration file is complex enough to use ts to have a significant benefit.

if they want to use imports/exports, they can do so by installing the plugin to compile them to CommonJS (or, we might just add it as a dependency of @babel/core and make it work by default maybe?)

It also looks odd to include @babel/plugin-transform-modules-commonjs in @babel/core. 😕
I'd rather release a new package that includes @babel/plugin-transform-modules-commonjs and ts.

Anyway thanks a lot for these results, I was also very curious but never did.🤦‍♂️

[nicolo-ribaudo]

@Andarist showed me that when using the intended TS "module" option for cts and mts files ("module": "Node16"), TS converts modules to CJS in .cts files and not in .mts files: nicolo-ribaudo/ts-experiment-cts-mts-behavior#1

I'm not opposed anymore to including the CommonJS transform in the preset, when compiling .cts files.

[liuxingbaoyu]

We should change this before merging.

[nicolo-ribaudo]

Before releasing, right? Could you add a notice in new-version-check in the makefile?

[nicolo-ribaudo]

Before releasing, right? Could you add a notice in new-version-check in the makefile?

[JLHwung]

LGTM pending the makefile new-version notes.

[liuxingbaoyu]

@nicolo-ribaudo Thanks!