[BUGFIX] Remove barrel file imports from internal code for better tree-shaking#21350
Open
NullVoxPopuli wants to merge 13 commits intomainfrom
Open
[BUGFIX] Remove barrel file imports from internal code for better tree-shaking#21350NullVoxPopuli wants to merge 13 commits intomainfrom
NullVoxPopuli wants to merge 13 commits intomainfrom
Conversation
Replace all internal barrel imports (from `@ember/-internals/glimmer`,
`@ember/-internals/environment`, etc.) with direct imports from the
specific source files that define what is needed. Also replace all
`export *` patterns in `@ember` packages with explicit named exports.
- Update ~40 source files to import from specific lib paths instead of
barrel `index.ts` files
- Replace `export *` with named exports in `@ember/-internals/environment`,
`@ember/engine/parent`, `@ember/template-compiler/*`, `ember-template-compiler`,
and `ember-testing`
- Replace `import * as environment` with named `{ hasDOM }` import in
`@ember/application/instance`
- Add deep import path entries to `@ember/-internals/package.json` exports map
- Add `@glimmer/opcode-compiler` dependency to `ember-template-compiler`
Test files are intentionally left unchanged as they may use barrel imports.
Contributor
📊 Package size report -0.44%↓
Show files (239 files)
🤖 This report was automatically generated by pkg-size-action |
NullVoxPopuli
changed the title
6 tasks
The smoke tests on #21350 fail with "Cannot read properties of null (reading 'syscall')" in `AppendOpcodes.evaluate`. Cause: the lint autofix replaced barrel imports of `@glimmer/runtime` with deep paths (`@glimmer/runtime/lib/...`), so nothing pulled in the package index. The index's `import './lib/bootstrap';` was the only thing loading the opcode handler files (each `lib/compiled/opcodes/*.ts` registers via top-level `APPEND_OPCODES.add(...)`), so 28 of 90 handlers stayed unregistered. Fix: own the bootstrap from the file that actually consumes registered handlers — `lib/vm/low-level.ts`, where `evaluateSyscall` calls `APPEND_OPCODES.evaluate(...)`. Any deep-import path that uses the VM (directly or transitively) now triggers bootstrap; consumers that don't need the VM don't pay for opcode handlers in their bundle. Verified by counting top-level `APPEND_OPCODES.add(...)` calls in `dist/dev`: origin/main: 90 in a chunk loaded by everyone nvp/remove-barrel-imports: 62 loaded + 28 trapped in the unused `@glimmer/runtime/index.js` this commit: 90 reachable from `@ember/-internals/glimmer/index.js` Note for reviewers: the validator duplicate-package guard in `@glimmer/validator/index.ts` and the `class EmberObject extends CoreObject.extend(Observable)` extension in `@ember/object/index.ts` are also barrel-only side effects. EmberObject's case is handled naturally — `import EmberObject from '@ember/object'` is a default import, which the lint rule's `kept` mechanism preserves on the barrel. The validator guard becomes dormant under deep imports; if that's a concern, move the registration check into a shared leaf module (e.g. `lib/meta.ts`) in a follow-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…imports-lint Preserve barrel side effects when rewriting deep imports
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The overall goal here is to be able to better analyze the dependency graph and not have arbitrary walls between packages, so that we can better refactor, trim away, and untangle all the imports.
Replace all internal imports with direct imports from the specific source files that define what is needed. Also replace all
export *patterns in@emberpackages with explicit named exports.This is... quite a bit more annoying for typing out imports.... but, it allows us to better progress towards more optimized bundles, and allows us to analyze all of ember-source, without having to go through our artificially created package entrypoints.
The entrypoints are unchanged, as they are public/intimate API, but our own code won't be using them (except in tests).
I've also created a lint to autofix any usages of these things, because doing it manually is a bad time.
Test files are intentionally left unchanged as they may use barrel imports.
Here is an example of where we can go next: #21354
TLDR ALREADY
smallest project possible (weekend warrior enablement)
goes from 77kb gzip to 37kb gzip