Wrong typescript emit path if --cwd is used

[katywings]

IS: If you use the cli cwd option to build a nested package xyz, the types are emitted into ./dist/.

SHOULD: Types should be emitted into the dist folder xyz/dist of the nested package.

DEMO:

• Clone https://github.com/katywings/microbundle-test/tree/65ba5c4aa436a9807969dbff9dcab30a9226cfc2
• npm install && ./scripts/build-devtools.js
• The types will be emitted into dist/devtools/lib/main.d.ts instead of devtools/dist/main.d.ts

REMARKS:

• If the devtools/lib/main.ts doesnt import something from an external, the ts emit path is different but still wrong: dist/main.d.ts
• Not directly related to the cwd thing, but I noticed that the --external cli option "freaks out" if the external has a dash character: microbundle prints: No name was provided for external module 'microbundle-test' in output.globals – guessing 'microbundleTest'. Doing the exact same bundle but naming the global "microbundletest" doesnt print this warning. (P.S. if you try this you also have to change the tsconfig.json path alias from microbundle-test to microbundletest)

[developit]

Ahh good point about external - we should be pre-populating the name when generating entry point externals but we aren't!

[developit]

Ah I found the cwd issue - we pass the package.json types path directly to rollup-plugin-typescript2, but should be resolving it against the cwd option value.

[katywings]

• P.S. i can't really make a fix regarding Wrong typescript emit path if --cwd is used #643 (comment) since I don't yet have the whole picture on how the entry point externals work together with different configurations.

• P.P.S. I looked at the situation regarding If the devtools/lib/main.ts doesnt import something from an external, the ts emit path is different but still wrong: dist/main.d.ts: it looks like this is closely related to Declaration generated in wrong folder when using object as input (multi-entry) ezolenko/rollup-plugin-typescript2#136, well its actually tsc that is doing it this way 🤦 . IMHO there is no way how we can solve this in microbundle nicely but I have an "alternative": what if microbundle would include a way to copy files from folder X to dist (like copy-webpack-plugin or something. Then the microbundle users could add type-proxy files to that folder X which would be copied by microbundle to the dist. - example of such a proxy file

[marvinhagemeister]

Fixed by #646 🎉

[katywings]

@marvinhagemeister Did you see my comment: #643 (comment) ?

There is actually one topic in this issue that wasnt fixed by my pr: #643 (comment) 😅

[marvinhagemeister]

@katywings oh I acted too quickly here. Sorry, that's on me 🙈

[developit]

@katywings I wonder - would it be possible for Microbundle to just generate that proxy types file with the correct name? I'd love to keep things as close to zero-config as possible.

[katywings]

@developit The problem is that typescript emits the types based on the structure of the source files including tsconfig path based "aliases".

Say you have a structure like this:

• preact/lib/main.ts (importing X from '../../utils.ts')
• utils.ts

Then the emit will be like

• preact/lib/main.d.ts

Because tsc tries to account for the ".." things

---

I cannot think of a non over-engineering solution which could automatically account for the different possible file structures 🤔

Edit: This is how I automatically created type proxies in witney before the large microbundle rework. But such an automatism only works if you force the consumers into a specific lib file structure ^^.

[katywings]

I kept thinking about what microbundle would need to do, to get correct dist types in all situations, but as I mentioned it, this is a very over engineered solution:

• Delete old dist (ideally via some parameter)
• Bundle as normal but add suffix "types" to declarationDir
• Detect if [source] has a default export
• Detect if [source] has other exports
• If dist/types/[sourcePathWithDTsEnding] exists: create type proxy file [pkg.types] that exports stuff from prev detection from dist/types/[sourcePathWithDTsEnding]
• else: create type proxy file [pkg.types] that exports stuff from prev detection from dist/types/[basename(pkg.types)]

I hope its clear what I mean, let me know otherwise xD.

[katywings]

Little update from my side: This is how I now handle the type proxies in my projects:

• Generation: https://github.com/alojs/alo/blob/d9807db69bd8ba62b296cfc007f4095aa40ba065/scripts/create-type-proxies.js#L5
• Workflow: https://github.com/alojs/alo/blob/d9807db69bd8ba62b296cfc007f4095aa40ba065/scripts/before-publish.js#L7
• Dist deletion: https://github.com/alojs/alo/blob/d9807db69bd8ba62b296cfc007f4095aa40ba065/scripts/build-core.js#L6