lint staged
v15.2.10
Exécutez des linters sur des fichiers git préparés et ne les laissez pas ? glissez-vous dans votre base de code !
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...
Le linting a plus de sens lorsqu'il est exécuté avant de valider votre code. Ce faisant, vous pouvez garantir qu'aucune erreur n'entre dans le référentiel et appliquer le style de code. Mais exécuter un processus de peluchage sur l’ensemble d’un projet est lent et les résultats du peluchage peuvent ne pas être pertinents. En fin de compte, vous souhaitez uniquement linter les fichiers qui seront validés.
Ce projet contient un script qui exécutera des tâches shell arbitraires avec une liste de fichiers intermédiaires comme argument, filtrée par un modèle global spécifié.
dotnet-format et lint-stagedSi vous en avez écrit un, veuillez soumettre un PR avec le lien vers celui-ci !
Pour installer lint-staging de la manière recommandée, vous devez :
npm install --save-dev lint-stagedpre-commit pour exécuter lint-staging{ "*.js": "eslint" } pour exécuter ESLint pour tous les fichiers JS préparés N'oubliez pas de valider les modifications apportées à package.json et .husky pour partager cette configuration avec votre équipe !
Maintenant, modifiez quelques fichiers, git add ou git add --patch certains d'entre eux dans votre commit et essayez de les git commit .
Voir les exemples et la configuration pour plus d'informations.
Voir les versions.
v15.0.0 Lint-Staged ne prend plus en charge Node.js 16. Veuillez mettre à niveau votre version de Node.js vers au moins 18.12.0 . v14.0.0 Lint-Staged ne prend plus en charge Node.js 14. Veuillez mettre à niveau votre version de Node.js vers au moins 16.14.0 . v13.0.0 Lint-Staged ne prend plus en charge Node.js 12. Veuillez mettre à niveau votre version de Node.js vers au moins 14.13.1 ou 16.0.0 et versions ultérieures.v13.3.0 n'a pas été publiée correctement, y compris le code de la version v14.0.0 . Cela signifie que les dernières modifications de v14 sont également incluses dans v13.3.0 , la dernière version v13 publiée. v12.0.0 lint-staged est un module ESM pur, assurez-vous donc que votre version de Node.js est au moins 12.20.0 , 14.13.1 ou 16.0.0 . En savoir plus sur les modules ESM sur le site de documentation officiel de Node.js ici. v10.0.0 , toute nouvelle modification apportée aux fichiers initialement préparés sera automatiquement ajoutée à la validation. Si votre tâche contenait auparavant une étape git add , veuillez la supprimer. Le comportement automatique garantit qu'il y a moins de conditions de concurrence, car essayer d'exécuter plusieurs opérations git en même temps entraîne généralement une erreur.v10.0.0 , lint-staging utilise les caches git pour améliorer la vitesse et fournir des sauvegardes pendant l'exécution. Étant donné que les caches git nécessitent au moins une validation initiale, vous ne devriez pas exécuter lint-staging dans un dépôt vide.v10.0.0 , la mise en scène lint nécessite Node.js version 10.13.0 ou ultérieure.v10.0.0 , lint-staging annulera la validation si les tâches linter annulent toutes les modifications effectuées. Pour autoriser la création d'un commit vide, veuillez utiliser l'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 : Par défaut, lorsque les tâches linter annulent toutes les modifications effectuées, lint-staging se termine avec une erreur et abandonne la validation. Utilisez cet indicateur pour autoriser la création de commits git vides.--concurrent [number|boolean] : Contrôle la simultanéité des tâches exécutées par lint-staging. REMARQUE : Cela n'affecte PAS la simultanéité des sous-tâches (elles seront toujours exécutées de manière séquentielle). Les valeurs possibles sont :false : exécutez toutes les tâches en sérietrue (par défaut) : concurrence infinie . Exécute autant de tâches en parallèle que possible.{number} : exécutez le nombre spécifié de tâches en parallèle, où 1 équivaut à false .--config [path] : spécifiez manuellement un chemin vers un fichier de configuration ou un nom de package npm. Remarque : lorsqu'il est utilisé, lint-staging n'effectuera pas la recherche du fichier de configuration et imprimera une erreur si le fichier spécifié est introuvable. Si '-' est fourni comme nom de fichier, la configuration sera lue à partir de stdin, permettant le transfert dans la configuration comme cat my-config.json | npx lint-staged --config - .--cwd [path] : Par défaut, les tâches s'exécutent dans le répertoire de travail actuel. Utilisez le --cwd some/directory pour remplacer cela. Le chemin peut être absolu ou relatif au répertoire de travail actuel.--debug : Exécuté en mode débogage. Une fois défini, il effectue les opérations suivantes :$DEBUG sur lint-staged* .verbose pour listr2 ; cela provoque une sortie série non colorée vers le terminal, au lieu de la sortie par défaut (embellifiée, dynamique). (le moteur de rendu verbose peut également être activé en définissant les variables d'environnement TERM=dumb ou NODE_ENV=test )--diff : Par défaut, les linters sont filtrés sur tous les fichiers préparés dans git, générés à partir de git diff --staged . Cette option vous permet de remplacer l'indicateur --staged par des révisions arbitraires. Par exemple, pour obtenir une liste des fichiers modifiés entre deux branches, utilisez --diff="branch1...branch2" . Vous pouvez également en savoir plus sur git diff et gitrevisions. Cette option implique également --no-stash .--diff-filter : Par défaut, seuls les fichiers ajoutés , copiés , modifiés ou renommés sont inclus. Utilisez cet indicateur pour remplacer la valeur ACMR par défaut par autre chose : ajouté ( A ), copié ( C ), supprimé ( D ), modifié ( M ), renommé ( R ), type modifié ( T ), non fusionné ( U ), inconnu ( X ), ou appariement rompu ( B ). Voir aussi la documentation git diff pour --diff-filter.--max-arg-length : les commandes longues (beaucoup de fichiers) sont automatiquement divisées en plusieurs morceaux lorsqu'il détecte que le shell actuel ne peut pas les gérer. Utilisez cet indicateur pour remplacer la longueur maximale de la chaîne de commande générée.--no-stash : Par défaut, une sauvegarde sera créée avant d'exécuter les tâches, et toutes les modifications des tâches seront annulées en cas d'erreur. Cette option désactivera la création du cache et laissera toutes les modifications dans l'index lors de l'abandon de la validation. Peut être réactivé avec --stash . Cette option implique également --no-hide-partially-staged .--no-hide-partially-staged : Par défaut, les modifications non préparées provenant de fichiers partiellement préparés seront masquées. Cette option désactivera ce comportement et inclura toutes les modifications non préparées dans les fichiers partiellement préparés. Peut être réactivé avec --hide-partially-staged--quiet : supprime toutes les sorties CLI, à l'exception des tâches.--relative : transmet les chemins de fichiers relatifs à process.cwd() (où les exécutions lint-staged ) aux tâches. La valeur par défaut est false .--shell : Par défaut, les commandes linter seront analysées pour des raisons de vitesse et de sécurité. Cela a pour effet secondaire que les scripts shell classiques peuvent ne pas fonctionner comme prévu. Vous pouvez ignorer l'analyse des commandes avec cette option. Pour utiliser un shell spécifique, utilisez un chemin comme --shell "/bin/bash" .--verbose : Afficher le résultat des tâches même lorsque les tâches réussissent. Par défaut, seule la sortie ayant échoué est affichée. Le Lint-Staging peut être configuré de plusieurs manières :
lint-staged dans votre package.json ou package.yaml.lintstagedrc au format JSON ou YML, ou vous pouvez être explicite avec l'extension de fichier :.lintstagedrc.json.lintstagedrc.yaml.lintstagedrc.yml.lintstagedrc.mjs ou lint-staged.config.mjs au format ESMexport default { ... }.lintstagedrc.cjs ou lint-staged.config.cjs au format CommonJSmodule.exports = { ... }lint-staged.config.js ou .lintstagedrc.js au format ESM ou CommonJS, selon que le package.json de votre projet contient ou non l'option "type": "module" .--config ou -cLa configuration doit être un objet où chaque valeur est une commande à exécuter et sa clé est un modèle global à utiliser pour cette commande. Ce package utilise micromatch pour les modèles globaux. Les fichiers JavaScript peuvent également exporter une configuration avancée en tant que fonction. Voir Utilisation des fichiers de configuration JS pour plus d'informations.
Vous pouvez également placer plusieurs fichiers de configuration dans différents répertoires d'un projet. Pour un fichier intermédiaire donné, le fichier de configuration le plus proche sera toujours utilisé. Voir « Comment utiliser lint-staged dans un monorepo multi-package ? » pour plus d'informations et un exemple.
package.json : {
"lint-staged" : {
"*" : " your-cmd "
}
}.lintstagedrc {
"*" : " your-cmd "
} Cette configuration exécutera your-cmd avec la liste des fichiers actuellement préparés passés en arguments.
Donc, étant donné que vous avez fait git add file1.ext file2.ext , lint-staged exécutera la commande suivante :
your-cmd file1.ext file2.ext
Par défaut, lint-staging exécutera les tâches configurées simultanément. Cela signifie que pour chaque glob, toutes les commandes seront lancées en même temps. Avec la configuration suivante, eslint et prettier fonctionneront en même temps :
{
"*.ts" : " eslint " ,
"*.md" : " prettier --list-different "
} Ce n'est généralement pas un problème puisque les globs ne se chevauchent pas et que les commandes n'apportent pas de modifications aux fichiers, mais signalent uniquement les erreurs possibles (abandonnant le commit git). Si vous souhaitez exécuter plusieurs commandes pour le même ensemble de fichiers, vous pouvez utiliser la syntaxe du tableau pour vous assurer que les commandes sont exécutées dans l'ordre. Dans l'exemple suivant, prettier s'exécutera pour les deux globs, et en plus eslint s'exécutera pour les fichiers *.ts après celui-ci. Les deux ensembles de commandes (pour chaque global) sont toujours lancés en même temps (mais ne se chevauchent pas).
{
"*.ts" : [ " prettier --list-different " , " eslint " ],
"*.md" : " prettier --list-different "
} Soyez particulièrement attentif lorsque les globes configurés se chevauchent et que les tâches modifient les fichiers. Par exemple, dans cette configuration, prettier et eslint pourraient essayer d'apporter des modifications au même fichier *.ts en même temps, provoquant une condition de concurrence critique :
{
"*" : " prettier --write " ,
"*.ts" : " eslint --fix "
}Vous pouvez le résoudre en utilisant le modèle de négation et la syntaxe du tableau :
{
"!(*.ts)" : " prettier --write " ,
"*.ts" : [ " eslint --fix " , " prettier --write " ]
}Un autre exemple dans lequel les tâches modifient les fichiers et les globes correspondent à plusieurs fichiers mais ne se chevauchent pas :
{
"*.css" : [ " stylelint --fix " , " prettier --write " ],
"*.{js,jsx}" : [ " eslint --fix " , " prettier --write " ],
"!(*.css|*.js|*.jsx)" : [ " prettier --write " ]
} Ou, si nécessaire, vous pouvez limiter la concurrence en utilisant --concurrent <number> ou la désactiver entièrement avec --concurrent false .
Les commandes Linter fonctionnent sur un sous-ensemble de tous les fichiers intermédiaires, définis par un modèle global . lint-staging utilise micromatch pour faire correspondre les fichiers avec les règles suivantes :
/ ), l'option matchBase de micromatch sera activée, de sorte que les globs correspondent au nom de base d'un fichier quel que soit le répertoire :"*.js" correspondra à tous les fichiers JS, comme /test.js et /foo/bar/test.js"!(*test).js" correspondra à tous les fichiers JS, sauf ceux se terminant par test.js , donc foo.js mais pas foo.test.js"!(*.css|*.js)" correspondra à tous les fichiers à l'exception des fichiers CSS et JS/ ), il correspondra également aux chemins :"./*.js" correspondra à tous les fichiers JS dans la racine du dépôt git, donc /test.js mais pas /foo/bar/test.js"foo/**/*.js" correspondra à tous les fichiers JS dans le répertoire /foo , donc /foo/bar/test.js mais pas /test.jsLors de la correspondance, lint-staged fera ce qui suit
REMARQUE : lint-staged transmettra des chemins absolus aux linters pour éviter toute confusion au cas où ils seraient exécutés dans un répertoire de travail différent (c'est-à-dire lorsque votre répertoire .git n'est pas le même que votre répertoire package.json ).
Voir également Comment utiliser lint-staged dans un monorepo multi-packages ?
Le concept de lint-staged consiste à exécuter des tâches linter configurées (ou d'autres tâches) sur des fichiers préparés dans git. lint-staged transmettra toujours une liste de tous les fichiers préparés à la tâche, et ignorer tous les fichiers doit être configuré dans la tâche elle-même.
Considérez un projet qui utilise prettier pour garder le format de code cohérent dans tous les fichiers. Le projet stocke également les bibliothèques minifiées de fournisseurs tiers dans le répertoire vendor/ . Pour éviter que prettier ne génère des erreurs sur ces fichiers, le répertoire du fournisseur doit être ajouté à la configuration ignorée de Prettier, le fichier .prettierignore . Exécuter npx prettier . ignorera l'intégralité du répertoire du fournisseur et ne générera aucune erreur. Lorsque lint-staged est ajouté au projet et configuré pour s'exécuter de manière plus jolie, tous les fichiers modifiés et préparés dans le répertoire du fournisseur seront ignorés par plus joli, même s'il les reçoit en entrée.
Dans les scénarios avancés, où il est impossible de configurer la tâche linter elle-même pour ignorer les fichiers, mais où certains fichiers intermédiaires doivent toujours être ignorés par lint-staged , il est possible de filtrer les chemins de fichiers avant de les transmettre aux tâches en utilisant la syntaxe de fonction. Voir Exemple : Ignorer les fichiers de la correspondance.
Tous les exécutables installés localement ou globalement via npm ainsi que tout exécutable à partir de votre $PATH sont pris en charge.
L'utilisation de scripts installés globalement est déconseillée, car la mise en scène lintée peut ne pas fonctionner pour quelqu'un qui ne l'a pas installé.
lint-staged utilise execa pour localiser les scripts installés localement. Ainsi dans votre .lintstagedrc vous pouvez écrire :
{
"*.js" : " eslint --fix "
} Cela entraînera l'exécution par lint de eslint --fix file-1.js file-2.js , lorsque vous aurez préparé les fichiers file-1.js , file-2.js et README.md .
Transmettez des arguments à vos commandes séparés par des espaces comme vous le feriez dans le shell. Voir les exemples ci-dessous.
Vous pouvez exécuter plusieurs commandes dans une séquence sur chaque globe. Pour ce faire, transmettez un tableau de commandes au lieu d’un seul. Ceci est utile pour exécuter des outils de formatage automatique comme eslint --fix ou stylefmt mais peut être utilisé pour n'importe quelle séquence arbitraire.
Par exemple:
{
"*.js" : [ " eslint " , " prettier --write " ]
} va exécuter eslint et s'il se termine avec 0 code, il exécutera prettier --write sur tous les fichiers *.js mis en scène.
Cela entraînera l'exécution par Lint eslint file-1.js file-2.js , lorsque vous aurez préparé les fichiers file-1.js , file-2.js et README.md , et s'il réussit, prettier --write file-1.js file-2.js .
L'écriture du fichier de configuration en JavaScript est le moyen le plus puissant de configurer lint-staged ( lint-staged.config.js , similaire ou transmis via --config ). A partir du fichier de configuration, vous pouvez exporter soit une seule fonction, soit un objet.
Si la valeur exports est une fonction, elle recevra un tableau de tous les noms de fichiers intermédiaires. Vous pouvez ensuite créer vos propres correspondants pour les fichiers et renvoyer une chaîne de commande ou un tableau de chaînes de commande. Ces chaînes sont considérées comme complètes et doivent inclure les arguments du nom de fichier, si vous le souhaitez.
Si la valeur exports est un objet, ses clés doivent être des correspondances globales (comme dans le format de configuration normal non-js). Les valeurs peuvent être soit celles de la configuration normale, soit celles des fonctions individuelles comme décrites ci-dessus. Au lieu de recevoir tous les fichiers correspondants, les fonctions de l'objet exporté recevront uniquement les fichiers préparés correspondant à la clé globale correspondante.
Pour résumer, par défaut, lint-staging ajoute automatiquement la liste des fichiers mis en scène correspondants à votre commande, mais lors de la création de la commande à l'aide des fonctions JS, il est prévu de le faire manuellement. Par exemple:
export default {
'*.js' : ( stagedFiles ) => [ `eslint .` , `prettier --write ${ stagedFiles . join ( ' ' ) } ` ] ,
} Cela entraînera la première exécution de eslint par étapes lint eslint . (correspondant à tous les fichiers), et si cela réussit, prettier --write file-1.js file-2.js , lorsque vous avez préparé des fichiers file-1.js , file-2.js et README.md .
La fonction peut également être asynchrone :
( 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 sur les modifications apportées aux fichiers TypeScript, mais ne transmettez aucun argument de nom de fichier // 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 ( ' ' ) } ` ,
}Il est préférable d'utiliser la configuration basée sur les fonctions (voir ci-dessus), si votre cas d'utilisation est le suivant.
// 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 ( ' ' ) } ` ]
} ,
} Si pour une raison quelconque vous souhaitez ignorer les fichiers de la correspondance globale, vous pouvez utiliser micromatch.not() :
// 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 ( ' ' ) } `
} ,
} Veuillez noter que dans la plupart des cas, les globs peuvent obtenir le même effet. Pour l'exemple ci-dessus, un glob correspondant serait !(*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 ( ' ' ) } `
} ,
} Des outils comme Prettier, ESLint/TSLint ou stylelint peuvent reformater votre code selon une configuration appropriée en exécutant prettier --write / eslint --fix / tslint --fix / stylelint --fix . Lint-staging ajoutera automatiquement toutes les modifications au commit tant qu'il n'y a pas d'erreurs.
{
"*.js" : " prettier --write "
} Avant la version 10, les tâches devaient inclure manuellement git add comme étape finale. Ce comportement a été intégré dans lint-staged lui-même afin d'éviter les conditions de concurrence avec plusieurs tâches éditant les mêmes fichiers. Si lint-staging détecte git add dans les configurations de tâches, il affichera un avertissement dans la console. Veuillez supprimer git add de votre configuration après la mise à niveau.
Tous les exemples supposent que vous avez déjà configuré lint-staging dans le fichier package.json et husky dans son propre fichier de configuration.
{
"name" : " My project " ,
"version" : " 0.1.0 " ,
"scripts" : {
"my-custom-script" : " linter --arg1 --arg2 "
},
"lint-staged" : {}
} Dans .husky/pre-commit
# .husky/pre-commit
npx lint-stagedRemarque : nous ne transmettons pas de chemin comme argument aux coureurs. Ceci est important puisque lint-staged le fera pour vous.
*.js et *.jsx exécutés en tant que hook de pré-validation{
"*.{js,jsx}" : " eslint "
}--fix et ajoutez-le au commit{
"*.js" : " eslint --fix "
} Cela exécutera eslint --fix et ajoutera automatiquement des modifications au commit.
Si vous souhaitez réutiliser un script npm défini dans votre package.json :
{
"*.js" : " npm run my-custom-script -- "
}Ce qui suit est équivalent :
{
"*.js" : " linter --arg1 --arg2 "
} Les commandes Linting ne prennent pas en charge la convention shell de développement des variables d'environnement. Pour activer la convention vous-même, utilisez un outil tel que cross-env .
Par exemple, voici jest exécuté sur tous les fichiers .js avec la variable NODE_ENV définie sur "test" :
{
"*.js" : [ " cross-env NODE_ENV=test jest --bail --findRelatedTests " ]
}prettier pour tous les formats pris en charge par Plus joli{
"*" : " prettier --ignore-unknown --write "
}prettier pour JavaScript, TypeScript, Markdown, HTML ou 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 est un outil CLI conçu pour une utilisation par étapes avec des valeurs par défaut raisonnables.
En savoir plus sur cet article de blog pour connaître les avantages de cette approche.
{
"*.{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 a introduit une modification dans les hooks où ils n'étaient plus exécutés dans le TTY d'origine. Cela a été corrigé dans la version 2.37.0 :
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.37.0.txt
- Dans Git 2.36, nous avons réorganisé la façon dont les hooks sont invoqués. Un changement visible par l'utilisateur final est que la sortie d'un hook n'est plus directement connectée à la sortie standard de "git" qui génère le hook, ce qui a été remarqué après la sortie. Ceci est en train d’être corrigé. (fusionner a082345372 ab/hooks-regression-fix plus tard avec maintenance).
Si la mise à jour de Git ne vous aide pas, vous pouvez essayer de rediriger manuellement la sortie dans votre hook Git ; Par exemple:
# .husky/pre-commit
if sh -c " : >/dev/tty " > /dev/null 2> /dev/null ; then exec > /dev/tty 2>&1 ; fi
npx lint-stagedSource : typicode/husky#968 (commentaire)
lint-staged via node ?Oui!
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 )
} Les paramètres de lintStaged sont équivalents à leurs homologues CLI :
const success = await lintStaged ( {
allowEmpty : false ,
c
