Add support of .mts and .cts extension as a variant of .ts files.

[alexhanga]

TypeScript supports .mts and .cts files, which corresponds to .mjs and .cts JS extensions. Right now these files are ignored by a plugin, which brings problems with ESM modules support.

[ArnaudBarre]

What is your usecase for using this extensions? Given that this prefix is not available for TSX files that are bundled with them, the module type should be decided by the bundler and not the extension

[alexhanga]

@ArnaudBarre We have a big mono-repo with vite + vitest. The problem that we encountered is that Vitest with this plugin treating .mts and .cts files as ecmascript files. Which brings errors about Incorrect syntax, because there's no transformer for them, but SWC can easily handle these files.

With babel version of this plugin it treats these files correctly, because it is not extension based. And right now as a hack we added flag to use babel for some packages that have .mts files. But it's not optimal.

[ArnaudBarre]

But my questions is why in the first place you have this extensions in your source? Why not just TS files?

[alexhanga]

@ArnaudBarre It was used to make clear that this is pure ESM file (while the rest of the project was transpiled to commonjs). And for some time it was recommended to use .mjs extension for esm files.

Anyway, it is a variant of .ts files which are supported by this plugin, so I don't understand why it's shouldn't be supported.

[ArnaudBarre]

The goal of this plugin is not to support everything possible in the other one. Reducing the scope of the plugin enable easier improvements in the future.

I don't think this is good that this plugin allows people to mixup source code with different module system. While bun was able to do it, this is a mess for the rest of the ecosystem and I don't want to deal with this kind of issues.

Source code in Vite should be in ESM. If you need commonjs for an eslint/postcss config or local scripts, you can use .cts in that case. For the rest I think assuming ESM for .ts is good and better than adding support for .mts.

And this what happen for .tsx anyway

[alexhanga]

@ArnaudBarre adding 2 new extensions is not limiting improvements, it's just cover what was missed before, because .mts and .cts is the same .ts files with only difference is that it results in .mjs and .cjs extensions after the transpilation.

Why it's useful?

1. In current state of react world if you try to use type: module and configure moduleResolution to node16 in tsconfig you will receive a lot of errors because react is not ESM package and other common packages like mui, redux, etc is not ESM as well.
2. Using .mts files forces TypeScript to treat this file as a ESM file while other files will function like it was before.

So adding support for .mts files is useful and also doesn't bring any new complexity or new functionality, it's just adding missed extension to already working solution.

[ArnaudBarre]

Please use bundler and not node16 to typecheck a React codebase.
I will add support for .mts but .cts doesn't make sense Vite doesn't support running code with require calls