Closed alexhanga closed 8 months ago
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
@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.
But my questions is why in the first place you have this extensions in your source? Why not just TS files?
@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.
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
@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?
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..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.
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
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.