fix: give each check its own linter rather than one per module - #356
Merged
Merged
Conversation
`stylelint-worker.js` held the path and the options in module variables, which is right for a worker — one thread, one linter — and wrong for the plugin's own thread, where every check calls `setup` on the same module. Two Stylelint entries therefore both linted under whichever was written last: an entry reporting `color-named` next to one configured with no rules reported nothing at all. The linter is a value now. A worker holds the one it was started with and the adapter holds one per check, which is the shape the typescript check already had around `typescript-program.js`. The eslint pair loaded the `ESLint` class twice over — once in the worker and once in the adapter. It is `loadESLintClass` in the worker now, which the adapter imports.
This was referenced Sep 14, 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
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.
Summary
Answering "why is there a
stylelint.jsand astylelint-worker.js" turned up a bug rather than a duplicate. The worker file held the path and the options in module variables — right for a worker, which is one thread and one linter, and wrong for the plugin's own thread, where every check calls the same module'ssetup. Two Stylelint entries therefore both linted under whichever was written last: an entry reportingcolor-namednext to one configured with no rules reported nothing at all (1 error alone, 0 together). It is the same family as #351, one level down.The linter is a value now: a worker holds the one it was started with, the adapter holds one per check. That is the shape the typescript check already had around
typescript-program.js, so all three pairs now agree.The eslint pair was the actual duplication — both halves loaded the
ESLintclass themselves. That isloadESLintClassin the worker now, which the adapter imports; no behaviour change, since suppressions and the typed-linting cache-off already run on the plugin's thread over the worker's results.What kind of change does this PR introduce?
fix.
Did you add tests for your changes?
Yes —
test/stylelint/multiple-checks.test.jsruns the reporting entry alone and then beside a silent one, and asserts the same report both times. It fails against unmodifiedsrc/.Does this PR introduce a breaking change?
No.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
n/a.
Use of AI
AI was used. It was asked why the worker files are separate, found the shared module state while answering, reproduced it as a two-entry build, and wrote the fix, the union and the test.
🤖 Generated with Claude Code
https://claude.ai/code/session_01GzZci4NQeiqwdrVfd7dGXy
Generated by Claude Code