lint staged
v15.2.10
Linters gegen bereitgestellte Git-Dateien ausführen und nicht zulassen? schlüpfen Sie in Ihre Codebasis!
npm install --save-dev lint-staged # requires further setup $ git commit
✔ Preparing lint-staged...
❯ Running tasks for staged files...
❯ packages/frontend/.lintstagedrc.json — 1 file
↓ *.js — no files [SKIPPED]
❯ *.{json,md} — 1 file
⠹ prettier --write
↓ packages/backend/.lintstagedrc.json — 2 files
❯ *.js — 2 files
⠼ eslint --fix
↓ *.{json,md} — no files [SKIPPED]
◼ Applying modifications from tasks...
◼ Cleaning up temporary files...
Linting ist sinnvoller, wenn es vor dem Festschreiben Ihres Codes ausgeführt wird. Auf diese Weise können Sie sicherstellen, dass keine Fehler in das Repository gelangen und den Codestil durchsetzen. Die Ausführung eines Lint-Prozesses für ein gesamtes Projekt ist jedoch langsam und die Linting-Ergebnisse können irrelevant sein. Letztendlich möchten Sie nur Dateien linten, die festgeschrieben werden.
Dieses Projekt enthält ein Skript, das beliebige Shell-Aufgaben mit einer Liste bereitgestellter Dateien als Argument ausführt, gefiltert nach einem angegebenen Glob-Muster.
dotnet-format und lint-stagedWenn Sie eines geschrieben haben, reichen Sie bitte eine PR mit dem Link dazu ein!
Um lint-staged auf die empfohlene Weise zu installieren, müssen Sie Folgendes tun:
npm install --save-dev lint-stagedpre-commit -Git-Hook so ein, dass er lint-staged ausgeführt wird{ "*.js": "eslint" } um ESLint für alle bereitgestellten JS-Dateien auszuführen Vergessen Sie nicht, Änderungen an package.json und .husky vorzunehmen, um dieses Setup mit Ihrem Team zu teilen!
Ändern Sie nun ein paar Dateien, fügen Sie einige davon git add oder git add --patch zu Ihrem Commit hinzu und versuchen Sie, sie mit git commit zu übertragen.
Weitere Informationen finden Sie unter Beispiele und Konfiguration.
Siehe Veröffentlichungen.
v15.0.0 unterstützt lint-staged Node.js 16 nicht mehr. Bitte aktualisieren Sie Ihre Node.js-Version auf mindestens 18.12.0 . v14.0.0 unterstützt lint-staged Node.js 14 nicht mehr. Bitte aktualisieren Sie Ihre Node.js-Version auf mindestens 16.14.0 . v13.0.0 unterstützt lint-staged Node.js 12 nicht mehr. Bitte aktualisieren Sie Ihre Node.js-Version auf mindestens 14.13.1 oder 16.0.0 höher.v13.3.0 wurde fälschlicherweise einschließlich des Codes der Version v14.0.0 veröffentlicht. Das bedeutet, dass die Breaking Changes von v14 auch in v13.3.0 enthalten sind, der letzten veröffentlichten v13 Version v12.0.0 lint-staged um ein reines ESM-Modul handelt, stellen Sie sicher, dass Ihre Node.js-Version mindestens 12.20.0 , 14.13.1 oder 16.0.0 ist. Weitere Informationen zu ESM-Modulen finden Sie hier auf der offiziellen Node.js-Dokumentationsseite. v10.0.0 werden alle neuen Änderungen an ursprünglich bereitgestellten Dateien automatisch zum Commit hinzugefügt. Wenn Ihre Aufgabe zuvor einen git add -Schritt enthielt, entfernen Sie diesen bitte. Das automatische Verhalten stellt sicher, dass es weniger Race-Conditions gibt, da der Versuch, mehrere Git-Operationen gleichzeitig auszuführen, normalerweise zu einem Fehler führt.v10.0.0 verwendet lint-staged Git-Stashes, um die Geschwindigkeit zu verbessern und während der Ausführung Backups bereitzustellen. Da Git-Stashes mindestens ein anfängliches Commit erfordern, sollten Sie lint-staged nicht in einem leeren Repo ausführen.v10.0.0 erfordert Lint-Staging die Node.js-Version 10.13.0 oder höher.v10.0.0 bricht lint-staged den Commit ab, wenn Linter-Aufgaben alle bereitgestellten Änderungen rückgängig machen. Um das Erstellen eines leeren Commits zu ermöglichen, verwenden Sie bitte die Option --allow-empty . ❯ npx lint-staged --help
Usage: lint-staged [options]
Options:
-V, --version output the version number
--allow-empty allow empty commits when tasks revert all staged changes (default: false)
-p, --concurrent <number|boolean> the number of tasks to run concurrently, or false for serial (default: true)
-c, --config [path] path to configuration file, or - to read from stdin
--cwd [path] run all tasks in specific directory, instead of the current
-d, --debug print additional debug information (default: false)
--diff [string] override the default "--staged" flag of "git diff" to get list of files. Implies
"--no-stash".
--diff-filter [string] override the default "--diff-filter=ACMR" flag of "git diff" to get list of files
--max-arg-length [number] maximum length of the command-line argument string (default: 0)
--no-stash disable the backup stash, and do not revert in case of errors. Implies
"--no-hide-partially-staged".
--no-hide-partially-staged disable hiding unstaged changes from partially staged files
-q, --quiet disable lint-staged’s own console output (default: false)
-r, --relative pass relative filepaths to tasks (default: false)
-x, --shell [path] skip parsing of tasks for better shell support (default: false)
-v, --verbose show task output even when tasks succeed; by default only failed output is shown
(default: false)
-h, --help display help for command
--allow-empty : Wenn Linter-Aufgaben alle bereitgestellten Änderungen rückgängig machen, wird lint-staged standardmäßig mit einem Fehler beendet und das Commit abgebrochen. Verwenden Sie dieses Flag, um das Erstellen leerer Git-Commits zu ermöglichen.--concurrent [number|boolean] : Steuert die Parallelität von Aufgaben, die von lint-staged ausgeführt werden. HINWEIS : Dies hat KEINE Auswirkungen auf die Parallelität von Unteraufgaben (sie werden immer nacheinander ausgeführt). Mögliche Werte sind:false : Alle Aufgaben nacheinander ausführentrue (Standard): Unendliche Parallelität. Führt so viele Aufgaben wie möglich parallel aus.{number} : Führen Sie die angegebene Anzahl von Aufgaben parallel aus, wobei 1 gleichbedeutend mit false ist.--config [path] : Geben Sie manuell einen Pfad zu einer Konfigurationsdatei oder einem NPM-Paketnamen an. Hinweis: Bei Verwendung führt lint-staged keine Suche nach Konfigurationsdateien durch und gibt eine Fehlermeldung aus, wenn die angegebene Datei nicht gefunden werden kann. Wenn „-“ als Dateiname angegeben wird, wird die Konfiguration von stdin gelesen, was eine Weiterleitung in der Konfiguration wie cat my-config.json | npx lint-staged --config - ermöglicht cat my-config.json | npx lint-staged --config - .--cwd [path] : Standardmäßig werden Aufgaben im aktuellen Arbeitsverzeichnis ausgeführt. Verwenden Sie --cwd some/directory um dies zu überschreiben. Der Pfad kann absolut oder relativ zum aktuellen Arbeitsverzeichnis sein.--debug : Im Debug-Modus ausführen. Wenn es festgelegt ist, geschieht Folgendes:$DEBUG auf lint-staged* gesetzt wird.verbose Renderer für listr2 ; Dies führt zu einer seriellen, ungefärbten Ausgabe an das Terminal anstelle der standardmäßigen (verschönerten, dynamischen) Ausgabe. (Der verbose Renderer kann auch durch Festlegen der Umgebungsvariablen TERM=dumb oder NODE_ENV=test aktiviert werden.)--diff : Standardmäßig werden Linters nach allen in Git bereitgestellten Dateien gefiltert, die aus git diff --staged generiert wurden. Mit dieser Option können Sie das Flag --staged mit beliebigen Revisionen überschreiben. Um beispielsweise eine Liste der geänderten Dateien zwischen zwei Zweigen zu erhalten, verwenden Sie --diff="branch1...branch2" . Sie können auch mehr über Git Diff und Gitrevisions lesen. Diese Option impliziert auch --no-stash .--diff-filter : Standardmäßig werden nur Dateien einbezogen, die hinzugefügt , kopiert , geändert oder umbenannt wurden. Verwenden Sie dieses Flag, um den Standard- ACMR Wert mit etwas anderem zu überschreiben: hinzugefügt ( A ), kopiert ( C ), gelöscht ( D ), geändert ( M ), umbenannt ( R ), Typ geändert ( T ), nicht zusammengeführt ( U ), unbekannt ( X ) oder Paarung unterbrochen ( B ). Siehe auch die git diff Dokumente für --diff-filter.--max-arg-length : Lange Befehle (viele Dateien) werden automatisch in mehrere Blöcke aufgeteilt, wenn festgestellt wird, dass die aktuelle Shell sie nicht verarbeiten kann. Verwenden Sie dieses Flag, um die maximale Länge der generierten Befehlszeichenfolge zu überschreiben.--no-stash : Standardmäßig wird ein Backup-Stash erstellt, bevor die Aufgaben ausgeführt werden, und alle Aufgabenänderungen werden im Fehlerfall rückgängig gemacht. Diese Option deaktiviert die Erstellung des Stashs und belässt stattdessen alle Änderungen im Index, wenn der Commit abgebrochen wird. Kann mit --stash wieder aktiviert werden. Diese Option impliziert auch --no-hide-partially-staged .--no-hide-partially-staged : Standardmäßig werden nicht bereitgestellte Änderungen von teilweise bereitgestellten Dateien ausgeblendet. Diese Option deaktiviert dieses Verhalten und schließt alle nicht bereitgestellten Änderungen in teilweise bereitgestellten Dateien ein. Kann mit --hide-partially-staged wieder aktiviert werden--quiet : Unterdrückt alle CLI-Ausgaben außer von Aufgaben.--relative : Übergeben Sie Dateipfade relativ zu process.cwd() (wo lint-staged ausgeführt wird) an Aufgaben. Der Standardwert ist false .--shell : Standardmäßig werden Linter-Befehle aus Gründen der Geschwindigkeit und Sicherheit analysiert. Dies hat den Nebeneffekt, dass normale Shell-Skripte möglicherweise nicht wie erwartet funktionieren. Mit dieser Option können Sie das Parsen von Befehlen überspringen. Um eine bestimmte Shell zu verwenden, verwenden Sie einen Pfad wie --shell "/bin/bash" .--verbose : Aufgabenausgabe anzeigen, auch wenn Aufgaben erfolgreich sind. Standardmäßig werden nur fehlgeschlagene Ausgaben angezeigt. Lint-staged kann auf viele Arten konfiguriert werden:
lint-staged Objekt in Ihrer package.json oder package.yaml.lintstagedrc Datei im JSON- oder YML-Format, oder Sie können die Dateierweiterung explizit angeben:.lintstagedrc.json.lintstagedrc.yaml.lintstagedrc.yml.lintstagedrc.mjs oder lint-staged.config.mjs Datei im ESM-Formatexport default { ... }.lintstagedrc.cjs oder lint-staged.config.cjs -Datei im CommonJS-Formatmodule.exports = { ... }lint-staged.config.js oder .lintstagedrc.js im ESM- oder CommonJS-Format, je nachdem, ob die package.json Ihres Projekts die Option "type": "module" enthält oder nicht.--config oder -cDie Konfiguration sollte ein Objekt sein, bei dem jeder Wert ein auszuführender Befehl ist und dessen Schlüssel ein Glob-Muster ist, das für diesen Befehl verwendet werden soll. Dieses Paket verwendet Micromatch für Glob-Muster. JavaScript-Dateien können auch erweiterte Konfigurationen als Funktion exportieren. Weitere Informationen finden Sie unter JS-Konfigurationsdateien verwenden.
Sie können auch mehrere Konfigurationsdateien in verschiedenen Verzeichnissen innerhalb eines Projekts platzieren. Für eine bestimmte bereitgestellte Datei wird immer die nächstgelegene Konfigurationsdatei verwendet. Siehe „Wie verwende ich lint-staged in einem Monorepo mit mehreren Paketen?“ Weitere Informationen und ein Beispiel finden Sie hier.
package.json -Beispiel: {
"lint-staged" : {
"*" : " your-cmd "
}
}.lintstagedrc Beispiel {
"*" : " your-cmd "
} Diese Konfiguration führt your-cmd mit der Liste der aktuell bereitgestellten Dateien aus, die als Argumente übergeben werden.
Wenn Sie also bedenken, dass Sie git add file1.ext file2.ext ausgeführt haben, führt lint-staged den folgenden Befehl aus:
your-cmd file1.ext file2.ext
Standardmäßig führt lint-staged konfigurierte Aufgaben gleichzeitig aus. Das bedeutet, dass für jeden Glob alle Befehle gleichzeitig gestartet werden. Mit der folgenden Konfiguration werden eslint und prettier gleichzeitig ausgeführt:
{
"*.ts" : " eslint " ,
"*.md" : " prettier --list-different "
} Dies stellt normalerweise kein Problem dar, da sich die Globs nicht überlappen und die Befehle keine Änderungen an den Dateien vornehmen, sondern nur mögliche Fehler melden (Abbruch des Git-Commits). Wenn Sie mehrere Befehle für denselben Dateisatz ausführen möchten, können Sie die Array-Syntax verwenden, um sicherzustellen, dass die Befehle in der richtigen Reihenfolge ausgeführt werden. Im folgenden Beispiel wird prettier für beide Globs ausgeführt, und zusätzlich wird eslint für die nachfolgenden *.ts Dateien ausgeführt. Beide Befehlssätze (für jeden Glob) werden weiterhin gleichzeitig gestartet (überlappen sich jedoch nicht).
{
"*.ts" : [ " prettier --list-different " , " eslint " ],
"*.md" : " prettier --list-different "
} Seien Sie besonders vorsichtig, wenn sich die konfigurierten Globs überschneiden und Aufgaben Änderungen an Dateien vornehmen. In dieser Konfiguration könnten beispielsweise prettier und eslint versuchen, gleichzeitig Änderungen an derselben *.ts Datei vorzunehmen, was zu einer Race-Bedingung führt:
{
"*" : " prettier --write " ,
"*.ts" : " eslint --fix "
}Sie können es mithilfe des Negationsmusters und der Array-Syntax lösen:
{
"!(*.ts)" : " prettier --write " ,
"*.ts" : [ " eslint --fix " , " prettier --write " ]
}Ein weiteres Beispiel, in dem Aufgaben Änderungen an Dateien vornehmen und Globs mit mehreren Dateien übereinstimmen, sich aber nicht überschneiden:
{
"*.css" : [ " stylelint --fix " , " prettier --write " ],
"*.{js,jsx}" : [ " eslint --fix " , " prettier --write " ],
"!(*.css|*.js|*.jsx)" : [ " prettier --write " ]
} Bei Bedarf können Sie die Parallelität auch mit --concurrent <number> einschränken oder mit --concurrent false vollständig deaktivieren.
Linter-Befehle arbeiten mit einer Teilmenge aller bereitgestellten Dateien, die durch ein Glob-Muster definiert sind. lint-staged verwendet Micromatch zum Abgleichen von Dateien mit den folgenden Regeln:
/ ) enthält, wird die matchBase Option von Micromatch aktiviert, sodass Globs unabhängig vom Verzeichnis mit dem Basisnamen einer Datei übereinstimmen:"*.js" stimmt mit allen JS-Dateien überein, z. B. /test.js und /foo/bar/test.js"!(*test).js" stimmt mit allen JS-Dateien überein, mit Ausnahme derjenigen, die auf test.js enden, also foo.js , aber nicht foo.test.js"!(*.css|*.js)" stimmt mit allen Dateien außer CSS- und JS-Dateien überein/ ) enthält, stimmt es auch mit Pfaden überein:"./*.js" stimmt mit allen JS-Dateien im Git-Repo-Stammverzeichnis überein, also mit /test.js , aber nicht mit /foo/bar/test.js"foo/**/*.js" stimmt mit allen JS-Dateien im Verzeichnis /foo überein, also mit /foo/bar/test.js , aber nicht mit /test.jsBeim Abgleich führt lint-staged Folgendes aus
HINWEIS: lint-staged übergibt absolute Pfade an die Linters, um Verwirrung zu vermeiden, falls sie in einem anderen Arbeitsverzeichnis ausgeführt werden (z. B. wenn Ihr .git -Verzeichnis nicht mit Ihrem package.json -Verzeichnis übereinstimmt).
Siehe auch Wie verwende ich lint-staged in einem Monorepo mit mehreren Paketen?
Das Konzept von lint-staged besteht darin, konfigurierte Linter-Aufgaben (oder andere Aufgaben) für Dateien auszuführen, die in Git bereitgestellt werden. lint-staged übergibt immer eine Liste aller bereitgestellten Dateien an die Aufgabe, und das Ignorieren aller Dateien sollte in der Aufgabe selbst konfiguriert werden.
Stellen Sie sich ein Projekt vor, das prettier verwendet, um das Codeformat in allen Dateien konsistent zu halten. Das Projekt speichert außerdem minimierte Bibliotheken von Drittanbietern im Verzeichnis vendor/ . Um zu verhindern, dass prettier Fehler in diesen Dateien auslöst, sollte das Vendor-Verzeichnis zur Ignorierungskonfiguration von Prettier, der Datei .prettierignore , hinzugefügt werden. npx prettier . ignoriert das gesamte Anbieterverzeichnis und gibt keine Fehler aus. Wenn lint-staged zum Projekt hinzugefügt und für die Ausführung von Prettier konfiguriert wird, werden alle geänderten und bereitgestellten Dateien im Herstellerverzeichnis von Prettier ignoriert, obwohl Prettier sie als Eingabe empfängt.
In fortgeschrittenen Szenarien, in denen es nicht möglich ist, die Linter-Aufgabe selbst so zu konfigurieren, dass sie Dateien ignoriert, aber einige bereitgestellte Dateien trotzdem von lint-staged ignoriert werden sollten, ist es möglich, Dateipfade mithilfe der Funktionssyntax zu filtern, bevor sie an Aufgaben übergeben werden. Siehe Beispiel: Dateien aus Übereinstimmung ignorieren.
Unterstützt werden alle ausführbaren Dateien, die lokal oder global über npm installiert werden, sowie alle ausführbaren Dateien aus Ihrem $PATH.
Von der Verwendung global installierter Skripte wird abgeraten, da „lint-staged“ möglicherweise nicht für jemanden funktioniert, der es nicht installiert hat.
lint-staged verwendet Execa, um lokal installierte Skripte zu finden. In Ihre .lintstagedrc können Sie also schreiben:
{
"*.js" : " eslint --fix "
} Dies führt dazu, dass eslint --fix file-1.js file-2.js lint-staged ausgeführt wird, wenn Sie die Dateien file-1.js , file-2.js und README.md bereitgestellt haben.
Übergeben Sie Argumente durch Leerzeichen getrennt an Ihre Befehle, wie Sie es auch in der Shell tun würden. Siehe Beispiele unten.
Sie können auf jedem Glob mehrere Befehle hintereinander ausführen. Übergeben Sie dazu ein Array von Befehlen anstelle eines einzelnen Befehls. Dies ist nützlich für die Ausführung von Autoformatierungstools wie eslint --fix oder stylefmt kann aber für beliebige beliebige Sequenzen verwendet werden.
Zum Beispiel:
{
"*.js" : [ " eslint " , " prettier --write " ]
} Ich werde eslint ausführen und wenn es mit 0 Code beendet wird, wird prettier --write für alle bereitgestellten *.js Dateien ausgeführt.
Dies führt dazu, dass eslint file-1.js file-2.js lint-staged ausgeführt wird, wenn Sie die Dateien file-1.js , file-2.js und README.md bereitgestellt haben, und wenn dies erfolgreich ist, prettier --write file-1.js file-2.js .
Das Schreiben der Konfigurationsdatei in JavaScript ist die leistungsstärkste Möglichkeit, lint-staged zu konfigurieren ( lint-staged.config.js , ähnlich oder über --config übergeben). Aus der Konfigurationsdatei können Sie entweder eine einzelne Funktion oder ein Objekt exportieren.
Wenn der exports eine Funktion ist, erhält er ein Array aller bereitgestellten Dateinamen. Anschließend können Sie Ihre eigenen Matcher für die Dateien erstellen und eine Befehlszeichenfolge oder ein Array von Befehlszeichenfolgen zurückgeben. Diese Zeichenfolgen gelten als vollständig und sollten bei Bedarf die Dateinamenargumente enthalten.
Wenn der exports ein Objekt ist, sollten seine Schlüssel Glob-Übereinstimmungen sein (wie im normalen Nicht-JS-Konfigurationsformat). Die Werte können entweder wie in der normalen Konfiguration oder einzelne Funktionen wie oben beschrieben sein. Anstatt alle übereinstimmenden Dateien zu empfangen, empfangen die Funktionen im exportierten Objekt nur die bereitgestellten Dateien, die dem entsprechenden Glob-Schlüssel entsprechen.
Zusammenfassend lässt sich sagen, dass lint-staged standardmäßig automatisch die Liste der übereinstimmenden bereitgestellten Dateien zu Ihrem Befehl hinzufügt. Wenn Sie den Befehl jedoch mithilfe von JS-Funktionen erstellen, wird erwartet, dass dies manuell erfolgt. Zum Beispiel:
export default {
'*.js' : ( stagedFiles ) => [ `eslint .` , `prettier --write ${ stagedFiles . join ( ' ' ) } ` ] ,
} Dies führt dazu, dass „eslint“ zuerst im Lint-Stadium ausgeführt wird eslint . (Übereinstimmung mit allen Dateien), und wenn es erfolgreich ist, prettier --write file-1.js file-2.js , wenn Sie die Dateien file-1.js , file-2.js und README.md bereitgestellt haben.
Die Funktion kann auch asynchron sein:
( filenames : string [ ] ) => string | string [ ] | Promise < string | string [ ] > // lint-staged.config.js
import micromatch from 'micromatch'
export default ( allStagedFiles ) => {
const shFiles = micromatch ( allStagedFiles , [ '**/src/**/*.sh' ] )
if ( shFiles . length ) {
return `printf '%sn' "Script files aren't allowed in src directory" >&2`
}
const codeFiles = micromatch ( allStagedFiles , [ '**/*.js' , '**/*.ts' ] )
const docFiles = micromatch ( allStagedFiles , [ '**/*.md' ] )
return [ `eslint ${ codeFiles . join ( ' ' ) } ` , `mdl ${ docFiles . join ( ' ' ) } ` ]
} // .lintstagedrc.js
export default {
'**/*.js?(x)' : ( filenames ) => filenames . map ( ( filename ) => `prettier --write ' ${ filename } '` ) ,
}tsc bei Änderungen an TypeScript-Dateien aus, übergeben Sie jedoch keine Dateinamenargumente // lint-staged.config.js
export default {
'**/*.ts?(x)' : ( ) => 'tsc -p tsconfig.json --noEmit' ,
} // .lintstagedrc.js
export default {
'**/*.js?(x)' : ( filenames ) =>
filenames . length > 10 ? 'eslint .' : `eslint ${ filenames . join ( ' ' ) } ` ,
}Für diesen Anwendungsfall ist es besser, die funktionsbasierte Konfiguration (siehe oben) zu verwenden.
// lint-staged.config.js
import micromatch from 'micromatch'
export default {
'*' : ( allFiles ) => {
const codeFiles = micromatch ( allFiles , [ '**/*.js' , '**/*.ts' ] )
const docFiles = micromatch ( allFiles , [ '**/*.md' ] )
return [ `eslint ${ codeFiles . join ( ' ' ) } ` , `mdl ${ docFiles . join ( ' ' ) } ` ]
} ,
} Wenn Sie aus irgendeinem Grund Dateien aus dem Glob-Match ignorieren möchten, können Sie micromatch.not() verwenden:
// lint-staged.config.js
import micromatch from 'micromatch'
export default {
'*.js' : ( files ) => {
// from `files` filter those _NOT_ matching `*test.js`
const match = micromatch . not ( files , '*test.js' )
return `eslint ${ match . join ( ' ' ) } `
} ,
} Bitte beachten Sie, dass Globs in den meisten Fällen den gleichen Effekt erzielen können. Für das obige Beispiel wäre ein passender Glob !(*test).js .
import path from 'path'
export default {
'*.ts' : ( absolutePaths ) => {
const cwd = process . cwd ( )
const relativePaths = absolutePaths . map ( ( file ) => path . relative ( cwd , file ) )
return `ng lint myProjectName --files ${ relativePaths . join ( ' ' ) } `
} ,
} Tools wie Prettier, ESLint/TSLint oder stylelint können Ihren Code entsprechend einer geeigneten Konfiguration neu formatieren, indem sie prettier --write / eslint --fix / tslint --fix / stylelint --fix ausführen. Lint-staged fügt automatisch alle Änderungen zum Commit hinzu, solange keine Fehler vorliegen.
{
"*.js" : " prettier --write "
} Vor Version 10 mussten Aufgaben als letzten Schritt manuell git add einschließen. Dieses Verhalten wurde in lint-staged selbst integriert, um Race Conditions zu verhindern, bei denen mehrere Aufgaben dieselben Dateien bearbeiten. Wenn lint-staged git add in Aufgabenkonfigurationen erkennt, wird eine Warnung in der Konsole angezeigt. Bitte entfernen Sie git add nach dem Upgrade aus Ihrer Konfiguration.
Bei allen Beispielen wird davon ausgegangen, dass Sie „lint-staged“ bereits in der Datei package.json und „husky“ in einer eigenen Konfigurationsdatei eingerichtet haben.
{
"name" : " My project " ,
"version" : " 0.1.0 " ,
"scripts" : {
"my-custom-script" : " linter --arg1 --arg2 "
},
"lint-staged" : {}
} In .husky/pre-commit
# .husky/pre-commit
npx lint-stagedHinweis: Wir übergeben den Läufern keinen Pfad als Argument. Dies ist wichtig, da lint-staged dies für Sie erledigt.
*.js und *.jsx die als Pre-Commit-Hook ausgeführt werden{
"*.{js,jsx}" : " eslint "
}--fix und fügen Sie ihn zum Festschreiben hinzu{
"*.js" : " eslint --fix "
} Dadurch wird eslint --fix ausgeführt und automatisch Änderungen zum Commit hinzugefügt.
Wenn Sie ein in Ihrer package.json definiertes npm-Skript wiederverwenden möchten:
{
"*.js" : " npm run my-custom-script -- "
}Folgendes ist äquivalent:
{
"*.js" : " linter --arg1 --arg2 "
} Linting-Befehle unterstützen die Shell-Konvention zum Erweitern von Umgebungsvariablen nicht . Um die Konvention selbst zu aktivieren, verwenden Sie ein Tool wie cross-env .
Hier wird zum Beispiel jest auf allen .js Dateien ausgeführt, wobei die Variable NODE_ENV auf "test" gesetzt ist:
{
"*.js" : [ " cross-env NODE_ENV=test jest --bail --findRelatedTests " ]
}prettier für jedes von Prettier unterstützte Format{
"*" : " prettier --ignore-unknown --write "
}prettier für JavaScript, TypeScript, Markdown, HTML oder CSS{
"*.{js,jsx,ts,tsx,md,html,css}" : " prettier --write "
}{
"*.css" : " stylelint " ,
"*.scss" : " stylelint --syntax=scss "
}{
"*.scss" : [ " postcss --config path/to/your/config --replace " , " stylelint " ]
}{
"*.{png,jpeg,jpg,gif,svg}" : " imagemin-lint-staged "
}imagemin-lint-stagedimagemin-lint-staged ist ein CLI-Tool, das für die Lint-Staging-Nutzung mit sinnvollen Standardeinstellungen entwickelt wurde.
Weitere Informationen zu den Vorteilen dieses Ansatzes finden Sie in diesem Blogbeitrag.
{
"*.{js,jsx}" : " flow focus-check "
} // .lintstagedrc.js
// See https://nextjs.org/docs/basic-features/eslint#lint-staged for details
const path = require ( 'path' )
const buildEslintCommand = ( filenames ) =>
`next lint --fix --file ${ filenames . map ( ( f ) => path . relative ( process . cwd ( ) , f ) ) . join ( ' --file ' ) } `
module . exports = {
'*.{js,jsx,ts,tsx}' : [ buildEslintCommand ] ,
} Git 2.36.0 führte eine Änderung an Hooks ein, bei denen diese im ursprünglichen TTY nicht mehr ausgeführt wurden. Dies wurde in 2.37.0 behoben:
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.37.0.txt
- In Git 2.36 haben wir die Art und Weise überarbeitet, wie Hooks aufgerufen werden. Eine für den Endbenutzer sichtbare Änderung besteht darin, dass die Ausgabe eines Hooks nicht mehr direkt mit der Standardausgabe von „git“ verbunden ist, die den Hook erzeugt, was nach der Veröffentlichung bemerkt wurde. Dies wird korrigiert. (a082345372 ab/hooks-regression-fix später mit maint zusammenführen).
Wenn das Aktualisieren von Git nicht hilft, können Sie versuchen, die Ausgabe in Ihrem Git-Hook manuell umzuleiten. Zum Beispiel:
# .husky/pre-commit
if sh -c " : >/dev/tty " > /dev/null 2> /dev/null ; then exec > /dev/tty 2>&1 ; fi
npx lint-stagedQuelle: typicode/husky#968 (Kommentar)
lint-staged via node verwenden?Ja!
import lintStaged from 'lint-staged'
try {
const success = await lintStaged ( )
console . log ( success ? 'Linting was successful!' : 'Linting failed!' )
} catch ( e ) {
// Failed to load configuration
console . error ( e )
} Parameter für lintStaged entsprechen ihren CLI-Gegenstücken:
const success = await lintStaged ( {
allowEmpty : false ,
c
