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

[katywings]

@developit I think I now understand, why microbundle-test as external showed the warnig No name was provided for external module 'microbundle-test' in output.globals – guessing 'microbundleTest, while microbundle as external didnt:

microbundle/src/index.js

Line 428 in 65df3c1

if (name.match(/^[a-z_$][a-z0-9_$]*$/)) {

Normally the externals are directly passed into globals, but this regex pattern [a-z0-9_$] doesn't accept the dash - character and so microbundle-test will not be included in the globals :D. What do you think about adding - to the regex as valid character?

[developit]

@katywings the trick there is that when something ends up in globals, Rollup will try to reference it from this/window:

import test from 'microbundle-test';
+
globals['microbundle-test'] = 'microbundle-test';

...will output:

(function(factory, global) {
    if (typeof define=='function' && define.amd) define(['microbundle-test'], factory);
    else if (typeof module != 'undefined') module.exports = factory(require('microbundle-test'));
    else global.foo = factory(global['microbundle-test']);
})(function(test){
}, this)

Most libraries use camelCase for their global variable names rather than dash-case, since it's the default in both Rollup and Webpack.

[katywings]

@developit The only thing still "open" in this thread is the topic about typescript proxies (#643 (comment))

Since I think that this would need a lot over engineering, I gonna close this issue :) - you can reopen if you think this really should be worked out in microbundle.