Skip to content

fix!: replace lintDirtyModulesOnly with lintOnStart - #320

Open
alexander-akait wants to merge 1 commit into
mainfrom
fix/lint-on-start
Open

fix!: replace lintDirtyModulesOnly with lintOnStart#320
alexander-akait wants to merge 1 commit into
mainfrom
fix/lint-on-start

Conversation

@alexander-akait

Copy link
Copy Markdown
Member

Summary

lintDirtyModulesOnly: true tapped watchRun alone, so a one-shot build ran the plugin and linted nothing at all — a CI build reporting a clean tree it never read. The option becomes lintOnStart, inverted and defaulting to true: it says whether the first compilation lints every file it covers. A build is nothing but a first compilation, so it lints either way; a watch run set to false stays quiet until a file is touched and then reports only what webpack rebuilds, which is what the old option was reached for.

Measured before the change, with the error fixture: a run() build reports 1 error by default and 0 with lintDirtyModulesOnly: true. No other bundler's plugin behaves that way — vite-plugin-checker lints a build under enableBuild: true, and vite-plugin-eslint2 is off under build but says so as its documented default. Neither has a setting that looks enabled and silently checks nothing.

Stacked on #319 — its three commits are in this branch and leave the diff once it merges. Review the last commit only.

What kind of change does this PR introduce?

fix

Did you add tests for your changes?

Yes — test/lint-on-start.test.js and test/stylelint/lint-on-start.test.js (renamed from lint-dirty-modules-only), each gaining a case that a build still lints with lintOnStart: false.

Does this PR introduce a breaking change?

Yes. lintDirtyModulesOnly is gone. lintDirtyModulesOnly: true becomes lintOnStart: false; leaving it unset was already the default and stays so. A build that relied on lintDirtyModulesOnly: true to skip linting will now lint — remove the plugin from that config instead.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

The lintOnStart option and both migration tables are updated in README.md in this PR; the webpack.js.org page needs the same rename after release.

Use of AI

AI was used. Claude Code investigated how the equivalent plugins for Vite, Rollup and esbuild behave in build versus watch, measured this plugin's own behaviour in both modes, then wrote the change, the tests and the documentation. Every claim in this description was verified by running it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GzZci4NQeiqwdrVfd7dGXy


Generated by Claude Code

`lintDirtyModulesOnly: true` tapped watchRun alone, so a one-shot build
ran the plugin and linted nothing at all — a CI build reporting a clean
tree it never read.

The option is now `lintOnStart`, inverted and defaulting to true: it says
whether the first compilation lints every file it covers. A build is
nothing but a first compilation, so it lints either way; a watch run set
to false stays quiet until a file is touched and then reports only what
webpack rebuilds, which is what the old option was reached for.

Every other bundler's plugin lints a build by default or says plainly
that it does not — vite-plugin-checker runs the whole lint under
enableBuild, and vite-plugin-eslint2 is off under build unless asked.
Neither has a setting that looks enabled and silently checks nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GzZci4NQeiqwdrVfd7dGXy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant