fix(bundler): skip barrel optimization for entry points with sideEffects#27710
fix(bundler): skip barrel optimization for entry points with sideEffects#27710
Conversation
The barrel imports optimization incorrectly applied to entry point files when the project's package.json had a `sideEffects` field. Since entry points have no `requested_exports` (nothing imports them within the bundle), the optimization marked all their imports as unused, producing empty output with dangling export references. Skip barrel optimization for entry points so all their exports are preserved as the public API of the bundle. Closes #27709 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (2)
WalkthroughAdds a guard in barrel import optimization to skip entry point files, preventing unwanted barrel optimization that affects public API exports. Introduces regression tests validating sideEffects field handling with re-exports during bundling. Changes
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
There was a problem hiding this comment.
LGTM — small, focused fix with good regression tests.
Extended reasoning...
Overview
This PR adds a 7-line early return in applyBarrelOptimizationImpl (src/bundler/barrel_imports.zig) that skips barrel optimization for entry points. Entry points have no requested_exports since nothing imports them within the bundle, so barrel optimization would incorrectly mark all their imports as unused when sideEffects is configured. The test file (test/regression/issue/27709.test.ts) adds two regression tests covering both sideEffects: ["./dist/index.js"] and sideEffects: false.
Security risks
None — this is a bundler optimization fix with no security implications.
Level of scrutiny
Moderate. The production code change is minimal and follows established patterns (linear scan over entry_points.items is used throughout bundle_v2.zig). The logic is straightforward: entry points should never be barrel-optimized because they define the public API of the bundle.
Other factors
- The entry point check is correctly positioned after the initial guards (optimize_imports, side_effects check, empty records check) but before the barrel verification loop.
- The test is placed in the correct location per CLAUDE.md conventions (
test/regression/issue/27709.test.ts). - Tests use
tempDirwithusingfor proper cleanup, and test viaBun.buildAPI which is appropriate for bundler regression tests. - No CODEOWNERS concerns — this is standard bundler code.
- The PR description notes all 46 existing barrel tests continue to pass.
| // of the bundle. Since nothing imports from them within the bundle, | ||
| // requested_exports will be empty, causing barrel optimization to | ||
| // incorrectly mark all their imports as unused. | ||
| for (this.graph.entry_points.items) |ep| { |
There was a problem hiding this comment.
Can you use std.mem.containsScalar?
Summary
package.jsonhas asideEffectsfieldrequested_exports(nothing imports them within the bundle), so the barrel optimization would mark all their imports as unused, producing empty output with dangling references likeexport{m as B,e as A};applyBarrelOptimizationImplto skip barrel optimization for entry pointsCloses #27709
Test plan
test/regression/issue/27709.test.tscovering bothsideEffects: ["./dist/index.js"]andsideEffects: falsetest/bundler/bundler_barrel.test.ts)🤖 Generated with Claude Code