Open brawaru opened 1 year ago
Hi and thanks for well explaining in issue. Primary support added vis #162. Please feel free to mention if you think something is not following up spec with new handler.
@pi0 I have quickly checked the 1.3.0 and it doesn't seem to produce valid output in the updated playground: https://stackblitz.com/edit/node-yk5rfx?file=package.json&view=editor :(
In the playground the output of mkdist should match the TypeScript output (pnpm build:tsc
):
farewells.d.cts
— DTS for farewells.cjs
farewells.cjs
— CJS modulegreetings.d.ts
— DTS for greetings.js
greetings.js
— CJS/ESM module depending on tsConfig.compilerOptions.module
/ pkgJson.type
?index.d.mts
— DTS for index.mjs
index.mjs
— ESM moduleCurrently it outputs (pnpm build:mkdist
):
falewells.d.cts
— DTS for farewells.cjs
(file missing)farewells.mjs
— ESM module (no declaration)greetings.d.ts
— DTS for greetings.js
(file missing)greetings.mjs
— ESM module (no declaration)index.d.mts
— DTS for index.mjs
index.mjs
— ESM module (contains unresolved imports)The test is also indeed flawed.
To simplify:
[filename].d.ts
files tell TypeScript ‘hey, there's [filename].js
, I'm a declaration for it’. Likewise, [filename].d.mts
is ‘there's [filename].mjs
’, and [filename].d.cts
is ‘there's [filename].cjs
’.
.mts
and .cts
in sources tell TypeScript how to compile these files regardless the config, .mts
compiles to ESM files with .mjs
extension, and .cts
to CJS with .cjs
.
While updating I noticed I used ext
argument (which I removed in updated playground), and I'm not sure how ext
argument can be applied in this scenario. Maybe it can affect only .js
/.ts
source files and override tsConfig.compilerOptions.module
/ pkgJson.type
, e.g. if you set it to mjs
, then all .js
source files will be emitted as .mjs
and have associated .d.mts
declarations, whereas .cjs
and .mjs
files are emitted as is.
Environment
mkdist 1.1.2 on Node.js 16.14.2, v18.14.0.
Reproduction
.mts
and.cts
files in yoursrc
directory.mkdist -d --ext js
Example project files
```ts // farewells.cts export function sayGoodbye(name: string) { console.log(`Goodbye, ${name}!`) } ``` ```ts // greetings.ts export function sayHello(name: string) { console.log(`Hello, ${name}!`) } ``` ```ts // index.mts import { sayHello } from './greetings.js' import { sayGoodbye } from './farewells.cjs' sayHello('World') sayGoodbye('World') ```StackBlitz example: https://stackblitz.com/edit/node-erv3qh?file=package.json&view=editor (use
pnpm build:tsc
to build with TypeScript andpnpm build:mkdist
to build withmkdist
,start
to run./dist/index.mjs
with Node).Describe the bug
mkdist
ignores.cts
and.mts
files and copies them as is instead of compiling them to.cjs
(+.d.cts
) and.mjs
(+.d.mts
) respectfully.Additional context
I could've tried to explain the importance of these file extensions on my own but Bing did a nicer job than me 😢
While this is a nice explanation, it fails to mention a few other important things:
If your file has a
.ts
extension, TypeScript always assumes the resulting file will have.js
extension. So if any of the files in your project imports the other file that has.ts
extension, and you useNode16
(NodeNext
) module resolution (which you very much should btw), TypeScript forces you to write import with.js
extension, which is incompatible withmkdist
, unless you force it in.js
extension mode (--ext js
), which you cannot do in environments likenuxt-module-builder
without patching it (which is exactly what I'm struggling with and what I am doing).The other important thing is that
.ts
,.cts
,.mts
on the declaration files imply the existence of the file with the same basename: that is,index.d.ts
says ‘the declaration file is forindex.js
’,a.d.cts
is ‘fora.cjs
’, andb.d.mts
is ‘forb.mjs
’. That becomes super important for libraries that ship with wildcardexports
inpackage.json
, as well helps you as developer to avoid writingtypes
condition which may or may not lead to a correct declaration file (withouttypes
export condition TypeScript looks for[basename].d.[ts/cts/mts]
).Logs
No response