Repository navigation
fix: stop CPU spikes in large monorepos - #130
Closed
omribarzik-gong wants to merge 2 commits into
Closed
omribarzik-gong wants to merge 2 commits into
omribarzik-gong wants to merge 2 commits into
Conversation
The extension's live file watchers (**/*.css|scss|sass|less) never honored cssVariables.blacklistFolders - only the initial workspace scan did. Every matching fs event anywhere in the workspace (e.g. node_modules, dist, storybook-static during pnpm install/builds/git checkouts) reached the language server and triggered a synchronous postcss/less/scss parse. On top of that, every batch of changes ran resolveAllVariableReferences() over the *entire* variable cache (not just the changed files), and onDidChangeConfiguration cleared the whole cache and re-scanned the workspace on any VS Code settings change, not just cssVariables.*. In a monorepo with thousands of matching stylesheets, these three combined into sustained CPU spikes. - Filter onDidChangeWatchedFiles events against blacklistFolders before parsing (mirrors the existing fast-glob ignore behavior). - Debounce resolveAllVariableReferences so a burst of file events triggers one resolve pass instead of one per notification. - Skip the cache clear + full re-scan in onDidChangeConfiguration unless the resolved cssVariables settings actually changed.
|
blacklistFolders is a denylist and was already re-applied to the
watcher in the previous commit, but lookupFiles (the allowlist - e.g.
scoping the extension to only a handful of design-token files) was
still only consulted by the initial scan. Any changed file matching
the client's hardcoded **/*.css|scss|sass|less watchers still got
parsed and merged into the cache regardless of how narrow lookupFiles
was configured, silently growing scope back out over a session.
Add isIncludedFile(), mirroring fastGlob(lookupFiles, { ignore:
blacklistFolders, cwd }) exactly: dynamic glob patterns are filtered
by the blacklist, but an explicit static file path in lookupFiles
always matches regardless of the blacklist (verified against fast-glob
directly - it never applies `ignore` to non-dynamic patterns).
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 extension's live file watchers (**/*.css|scss|sass|less) never honored cssVariables.blacklistFolders - only the initial workspace scan did. Every matching fs event anywhere in the workspace (e.g. node_modules, dist, storybook-static during pnpm install/builds/git checkouts) reached the language server and triggered a synchronous postcss/less/scss parse.
On top of that, every batch of changes ran resolveAllVariableReferences() over the entire variable cache (not just the changed files), and onDidChangeConfiguration cleared the whole cache and re-scanned the workspace on any VS Code settings change, not just cssVariables.*.
In a monorepo with thousands of matching stylesheets, these three combined into sustained CPU spikes.