fix(tsconfig): stop reporting tsconfig files as file dependencies - #291
Merged
Conversation
Temporary workaround for the memory burst in monorepos with project references. Restoring is a one-commit revert: uncomment the loop in `load_tsconfig_paths` and drop the `#[ignore]` on `tsconfig_file_as_file_dependencies`.
Contributor
There was a problem hiding this comment.
Pull request overview
Reduces per-module memory growth during tsconfig path-alias resolution by no longer copying the accumulated TsConfig::file_dependencies set into ResolveContext (which downstream consumers keep per module).
Changes:
- Stop adding
tsconfig.file_dependenciesintoResolveContextduringload_tsconfig_paths. - Ignore the existing test that asserted tsconfig configs/references are reported as file dependencies (preserving it as a reference for later restoration).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/lib.rs | Disables propagation of tsconfig.file_dependencies into ResolveContext to prevent module count × tsconfig count scaling in downstream memory usage. |
| src/tests/tsconfig_project_references.rs | Marks the prior “tsconfig configs are file deps” assertion test as ignored while the workaround is in place. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
hardfist
approved these changes
Aug 11, 2026
2 tasks
This was referenced Aug 21, 2026
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
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.
Why
load_tsconfig_pathspushed the whole accumulatedtsconfig.file_dependenciesset — the root tsconfig, everything itextends, and every transitive project reference — intoResolveContexton every resolution that hit a tsconfig path alias.In a monorepo with project references that set is large, and the consumer keeps it per module, so the cost scales as
module count × tsconfig count. That is the memory burst this PR addresses.Here is an issue from user web-infra-dev/rspack#15021
Resolving
@/index.tsin theproject_referencesfixture:Before — 6 tsconfig paths on top of the real dependencies:
After:
Trade-off
This is a temporary workaround, not a fix. Editing a
tsconfig.json, a config it extends, or a referenced tsconfig no longer invalidates anything in watch mode — a dev server restart is required.It is written to be undone in one commit:
load_tsconfig_pathsis commented out rather than deleted, with aTODOpointing at the testtsconfig_file_as_file_dependenciesis marked#[ignore]rather than removed, so the expected dependency set stays recordedTsConfig::file_dependenciesand its accumulation inextend_tsconfig/load_referencesare untouchedRestoring means uncommenting the loop and dropping the
#[ignore].