commit-sheriff 1.6.0 → 1.6.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +19 -7
- package/bin/commit-sheriff.js +14 -3
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -247,13 +247,19 @@ The default config added by `init` (only if you don't already have one):
|
|
|
247
247
|
```json
|
|
248
248
|
{
|
|
249
249
|
"lint-staged": {
|
|
250
|
-
"*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"],
|
|
250
|
+
"*.{js,jsx,ts,tsx}": ["eslint --fix --max-warnings=0", "prettier --write"],
|
|
251
251
|
"*.{json,md,css,scss,html}": ["prettier --write"]
|
|
252
252
|
}
|
|
253
253
|
}
|
|
254
254
|
```
|
|
255
255
|
|
|
256
|
-
|
|
256
|
+
`--max-warnings=0` is there on purpose: ESLint only fails (non-zero exit) on errors by default, so
|
|
257
|
+
a rule set to `"warn"` (e.g. many "recommended" configs' default severity for unused imports) would
|
|
258
|
+
otherwise print in the terminal but still let the commit through looking clean.
|
|
259
|
+
|
|
260
|
+
Adjust freely — `commit-sheriff` doesn't overwrite it once present. That also means this default
|
|
261
|
+
only lands on **new** setups; if your project already has a `lint-staged` block from before this
|
|
262
|
+
change, add `--max-warnings=0` to it by hand to get the same behavior.
|
|
257
263
|
|
|
258
264
|
## Advanced: ESLint module-boundary template (TypeScript/React)
|
|
259
265
|
|
|
@@ -304,16 +310,22 @@ It installs whatever it needs automatically (via `npm install --save-dev`, same
|
|
|
304
310
|
`lint-staged`/`eslint`/`prettier`), skipping anything already present:
|
|
305
311
|
|
|
306
312
|
```bash
|
|
307
|
-
npm install --save-dev eslint@^9 typescript @typescript-eslint/parser \
|
|
308
|
-
@typescript-eslint/eslint-plugin @eslint/js @eslint/eslintrc eslint-plugin-sonarjs \
|
|
313
|
+
npm install --save-dev eslint@^9 typescript@^5 @typescript-eslint/parser \
|
|
314
|
+
@typescript-eslint/eslint-plugin @eslint/js@^9 @eslint/eslintrc eslint-plugin-sonarjs \
|
|
309
315
|
eslint-plugin-import eslint-plugin-prettier eslint-config-prettier eslint-plugin-react \
|
|
310
316
|
eslint-plugin-react-hooks eslint-plugin-jsx-a11y eslint-plugin-testing-library \
|
|
311
317
|
@vitest/eslint-plugin eslint-plugin-jest prettier
|
|
312
318
|
```
|
|
313
319
|
|
|
314
|
-
`eslint`
|
|
315
|
-
|
|
316
|
-
|
|
320
|
+
`eslint`, `@eslint/js`, and `typescript` are pinned on purpose rather than left to resolve to
|
|
321
|
+
whatever `latest` is — the plugin ecosystem here regularly lags behind both. Two concrete
|
|
322
|
+
conflicts this has already caused: `@eslint/js`'s own `latest` declares a hard peer on
|
|
323
|
+
`eslint@^10`, so leaving it unpinned next to `eslint@^9` is an instant `ERESOLVE`; and
|
|
324
|
+
`@typescript-eslint/eslint-plugin` currently only supports `typescript` up to `<6.1.0`, so an
|
|
325
|
+
unpinned `typescript` install (which resolves to its own `latest`, e.g. `7.x`) crashes plugin
|
|
326
|
+
loading with "typescript-eslint does not support TS 7.0". Pinning `eslint`/`@eslint/js` together
|
|
327
|
+
to `^9` and `typescript` to `^5` keeps the whole toolchain on versions that are actually
|
|
328
|
+
compatible with each other today.
|
|
317
329
|
|
|
318
330
|
If the install fails (offline, registry issue, etc.), it prints this exact command so you can run
|
|
319
331
|
it yourself.
|
package/bin/commit-sheriff.js
CHANGED
|
@@ -38,7 +38,10 @@ const DEFAULT_COMMIT_GUARD = {
|
|
|
38
38
|
};
|
|
39
39
|
|
|
40
40
|
const DEFAULT_LINT_STAGED = {
|
|
41
|
-
|
|
41
|
+
// --max-warnings=0: without this, ESLint only fails (non-zero exit) on errors — a warning
|
|
42
|
+
// (e.g. many "recommended" configs' default severity for unused imports) prints in the
|
|
43
|
+
// terminal but still lets `eslint --fix` exit 0, so the commit goes through looking clean.
|
|
44
|
+
"*.{js,jsx,ts,tsx}": ["eslint --fix --max-warnings=0", "prettier --write"],
|
|
42
45
|
"*.{json,md,css,scss,html}": ["prettier --write"],
|
|
43
46
|
};
|
|
44
47
|
|
|
@@ -199,11 +202,19 @@ function init() {
|
|
|
199
202
|
const ESLINT_REACT_DEV_DEPS = [
|
|
200
203
|
// Pinned (not left to resolve to "latest") — see the comment on the eslint@^9 install in
|
|
201
204
|
// mergeConfig() for why: the plugin ecosystem here regularly lags behind ESLint's newest major.
|
|
205
|
+
// @eslint/js in particular is versioned in lockstep with ESLint core and its `latest` (10.x)
|
|
206
|
+
// declares a hard peerDependency on eslint@^10 — installing it unpinned alongside eslint@^9
|
|
207
|
+
// produces an immediate ERESOLVE conflict, which is exactly what this pin prevents.
|
|
202
208
|
"eslint@^9",
|
|
203
|
-
|
|
209
|
+
// Same lag problem, different package: @typescript-eslint/eslint-plugin@8.65.0 declares
|
|
210
|
+
// `typescript: ">=4.8.4 <6.1.0"` as a peer, but unpinned "typescript" resolves to npm's
|
|
211
|
+
// "latest" (7.x once TypeScript ships a 7.0) — that's outside the supported range and
|
|
212
|
+
// crashes plugin loading with "typescript-eslint does not support TS 7.0". Pinning to the
|
|
213
|
+
// latest 5.x line keeps us inside the range the plugin actually supports today.
|
|
214
|
+
"typescript@^5",
|
|
204
215
|
"@typescript-eslint/parser",
|
|
205
216
|
"@typescript-eslint/eslint-plugin",
|
|
206
|
-
"@eslint/js",
|
|
217
|
+
"@eslint/js@^9",
|
|
207
218
|
"@eslint/eslintrc",
|
|
208
219
|
"eslint-plugin-sonarjs",
|
|
209
220
|
"eslint-plugin-import",
|