-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Ensure named exports are prioritized over wildcard re-exports #7016
Conversation
|
Benchmark ResultsKitchen Sink ✅
Timings
Cold Bundles
Cached Bundles
React HackerNews ✅
Timings
Cold BundlesNo bundle changes detected. Cached BundlesNo bundle changes detected. AtlasKit Editor ✅
Timings
Cold Bundles
Cached Bundles
Three.js ✅
Timings
Cold BundlesNo bundle changes detected. Cached BundlesNo bundle changes detected. |
@mischnic what action do I need to take to have this fix? |
Use any version of Parcel 2. |
@mischnic With regards to parcel I have below and still experiencing same error. "dependencies": { "devDependencies": { |
Please open a new issue with a complete code example to reproduce the error (and you didn't actually say exactly what the error is that you're getting). |
Fixes #6344. Fixes #6970.
The ES module spec says that named exports should be prioritized over wildcard re-exports. This updates our helpers to skip keys that are already defined when performing a wildcard re-export. This is safe because we hoist named exports to the top of the module, so by the time the helper is called, all named exports are already defined.
Previously, we either errored when trying to read the previous value (non scope-hoisting), errored when trying to re-define the property (scope hoisting with multiple re-exports), or overwrote the value with the later one (scope hoisting). Now the value is consistent across all cases.
Note: duplicate wildcard re-exports is still not fully spec compliant, but we can address this separately. According to the spec, ambiguous re-exports should be completely omitted from the namespace object, but should error when performing a named import. We currently will return the first value instead. Unfortunately, it seems most tools are inconsistent in this regard.