New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always respect synthetic namespaces in namespace reexports #3894
Conversation
Thank you for your contribution! ❤️You can try out this pull request locally by installing Rollup via
or load it into the REPL: |
Codecov Report
@@ Coverage Diff @@
## master #3894 +/- ##
=======================================
Coverage 97.08% 97.08%
=======================================
Files 187 187
Lines 6556 6563 +7
Branches 1910 1913 +3
=======================================
+ Hits 6365 6372 +7
Misses 101 101
Partials 90 90
Continue to review full report at Codecov.
|
What if reexport from two files with synthetic namespaces? I try to repl it with repl.it, but, unfortunately, I cannot use github version of rollup
|
The first one wins. Which is somewhat correct in so far as the first one already contains all possible exports. Of course this does not take into account that a real runtime would warn/throw in such a scenario if there are conflicting exports in the namespaces or return undefined (cannot remember which, but one of those). But I am inclined to accept that. |
So it means if the first export all namespace has syntheticNamedExports, all other ones are ignored. I guess Rollup should warn about this case. |
Alternatively we could track synthetic exports and build the resolve order like:
|
I think there is also case about reexport all from external module? It's really simlar cases for rollup. |
Does it possible to "merge" this synthetic namespaces at runtime? I.E., instead of export * from './synthetic1.js';
export * from './synthetic2.js';
export * from './external.js'; will be import {__moduleExports} from './synthetic1.js';
import {__moduleExports2} from './synthetic2.js';
import * as ext from './external.js';
//this will be marked as synthetic export by rollup itself, optionally will throw on non-existing key access
export const mergedSynthetic = {...__moduleExports, ...__moduleExports2, ...ext} |
Also, this opens possibility for external synthetic named exports. Just merge SNE export after external namespace and all is ok! |
This is not true. Run the following example in a browser in a // index.js
import { foo } from './other.js';
console.log(foo);
// other.js
export * from './a.js';
export * from './b.js';
// a.js
export const foo = 'a';
// b.js
export const foo = 'b'; This example will just throw: There is no order between star reexports because in case of conflict, the engine just throws for named imports. If you replace |
In a manner of speaking, all external imports have synthetic named exports. You have always been able to import what you want from an external import. |
Yep, but still it can be useful for certain use-cases. My interest is simple - I want to make incremental compiling for dev mode, and here external synthetic exports is really needed. About star reexports it's strange, I thought that I tested this on real runtimes. But maybe I tested it on rollup itself... |
As mentioned in #3928 (comment), I'd give a right arm for something mostly working to unblock the builds I'm attempting to put together. Just ran into this and it's a hard block. |
And @guybedford approves :D |
I will have another look tomorrow and see if we can release this. Or maybe slightly improve the logic first. |
dee96fc
to
c43556b
Compare
I slightly changed the logic now: If a file contains namespace reexports from more than one file and the first file has synthetic named exports, then explicit named exports from the second file will have higher precedence than synthetic exports from the first file. While this is still a heuristic, I believe it will usually be closer to user's expectations. |
Thanks for making this happen! |
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
#3857
resolves #3928
Description
This will treat synthetic namespaces as containing "all named exports" also when handling namespace reexports, i.e.
should work now.