lint staged
v15.2.10
Ejecute linters contra archivos git preparados y no lo permita. ¡deslízate en tu base de código!
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 tiene más sentido cuando se ejecuta antes de enviar su código. Al hacerlo, puede asegurarse de que no entren errores en el repositorio y aplicar el estilo del código. Pero ejecutar un proceso de pelusa en un proyecto completo es lento y los resultados de pelusa pueden ser irrelevantes. En última instancia, solo desea eliminar los archivos que se enviarán.
Este proyecto contiene un script que ejecutará tareas de shell arbitrarias con una lista de archivos preparados como argumento, filtrados por un patrón global específico.
dotnet-format y lint-stagedSi ha escrito uno, envíe un PR con el enlace.
Para instalar lint-staged de la manera recomendada, necesita:
npm install --save-dev lint-stagedpre-commit para ejecutar lint-staged{ "*.js": "eslint" } para ejecutar ESLint para todos los archivos JS preparados ¡No olvides realizar cambios en package.json y .husky para compartir esta configuración con tu equipo!
Ahora cambie algunos archivos, git add o git add --patch algunos de ellos en su confirmación e intente git commit .
Consulte ejemplos y configuración para obtener más información.
Ver lanzamientos.
v15.0.0 lint-staged ya no es compatible con Node.js 16. Actualice su versión de Node.js al menos a 18.12.0 . v14.0.0 lint-staged ya no es compatible con Node.js 14. Actualice su versión de Node.js al menos a 16.14.0 . v13.0.0 lint-staged ya no es compatible con Node.js 12. Actualice su versión de Node.js al menos a 14.13.1 o 16.0.0 en adelante.v13.3.0 se publicó incorrectamente, incluido el código de la versión v14.0.0 . Esto significa que los cambios importantes de v14 también se incluyen en v13.3.0 , la última versión v13 lanzada. v12.0.0 lint-staged es un módulo ESM puro, asegúrese de que su versión de Node.js sea al menos 12.20.0 , 14.13.1 o 16.0.0 . Lea más sobre los módulos ESM en el sitio de documentación oficial de Node.js aquí. v10.0.0 , cualquier modificación nueva a los archivos preparados originalmente se agregará automáticamente a la confirmación. Si su tarea anteriormente contenía un paso git add , elimínelo. El comportamiento automático garantiza que haya menos condiciones de carrera, ya que intentar ejecutar múltiples operaciones de git al mismo tiempo generalmente resulta en un error.v10.0.0 en adelante, lint-staged utiliza git stashes para mejorar la velocidad y proporcionar copias de seguridad mientras se ejecuta. Dado que git stashes requiere al menos una confirmación inicial, no debes ejecutar lint-staged en un repositorio vacío.v10.0.0 , lint-staged requiere la versión 10.13.0 o posterior de Node.js.v10.0.0 en adelante, lint-staged cancelará la confirmación si las tareas de linter deshacen todos los cambios programados. Para permitir la creación de una confirmación vacía, utilice la opción --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 : De forma predeterminada, cuando las tareas de linter deshacen todos los cambios programados, lint-staged saldrá con un error y cancelará la confirmación. Utilice esta bandera para permitir la creación de confirmaciones de git vacías.--concurrent [number|boolean] : controla la simultaneidad de las tareas que ejecuta lint-staged. NOTA : Esto NO afecta la simultaneidad de las subtareas (siempre se ejecutarán de forma secuencial). Los valores posibles son:false : ejecuta todas las tareas en serietrue (predeterminado): simultaneidad infinita . Ejecuta tantas tareas en paralelo como sea posible.{number} : ejecuta el número especificado de tareas en paralelo, donde 1 equivale a false .--config [path] : especifique manualmente una ruta a un archivo de configuración o al nombre del paquete npm. Nota: cuando se usa, lint-staged no realizará la búsqueda del archivo de configuración e imprimirá un error si no se puede encontrar el archivo especificado. Si se proporciona '-' como nombre de archivo, la configuración se leerá desde la entrada estándar, lo que permitirá canalizaciones en la configuración como cat my-config.json | npx lint-staged --config - .--cwd [path] : de forma predeterminada, las tareas se ejecutan en el directorio de trabajo actual. Utilice el --cwd some/directory para anular esto. La ruta puede ser absoluta o relativa al directorio de trabajo actual.--debug : Ejecutar en modo de depuración. Cuando se configura, hace lo siguiente:$DEBUG en lint-staged* .verbose para listr2 ; esto provoca una salida en serie sin color al terminal, en lugar de la salida predeterminada (embellecida, dinámica). (El renderizador verbose también se puede activar configurando las variables de entorno TERM=dumb o NODE_ENV=test )--diff : de forma predeterminada, los linters se filtran contra todos los archivos preparados en git, generados a partir de git diff --staged . Esta opción le permite anular el indicador --staged con revisiones arbitrarias. Por ejemplo, para obtener una lista de archivos modificados entre dos ramas, use --diff="branch1...branch2" . También puede leer más sobre git diff y girevisions. Esta opción también implica --no-stash .--diff-filter : De forma predeterminada, solo se incluyen los archivos que se agregan , copian , modifican o renombran . Utilice este indicador para anular el valor ACMR predeterminado con algo más: agregado ( A ), copiado ( C ), eliminado ( D ), modificado ( M ), renombrado ( R ), tipo cambiado ( T ), no fusionado ( U ), desconocido ( X ), o emparejamiento roto ( B ). Consulte también los documentos git diff para --diff-filter.--max-arg-length : los comandos largos (muchos archivos) se dividen automáticamente en varios fragmentos cuando detecta que el shell actual no puede manejarlos. Utilice esta bandera para anular la longitud máxima de la cadena de comando generada.--no-stash : de forma predeterminada, se creará una copia de seguridad antes de ejecutar las tareas y todas las modificaciones de las tareas se revertirán en caso de error. Esta opción deshabilitará la creación del alijo y, en su lugar, dejará todas las modificaciones en el índice al cancelar la confirmación. Se puede volver a habilitar con --stash . Esta opción también implica --no-hide-partially-staged .--no-hide-partially-staged : de forma predeterminada, se ocultarán los cambios no preparados de archivos parcialmente preparados. Esta opción deshabilitará este comportamiento e incluirá todos los cambios no preparados en archivos parcialmente preparados. Se puede volver a habilitar con --hide-partially-staged--quiet : suprime toda la salida CLI, excepto las tareas.--relative : pasa rutas de archivos relativas a process.cwd() (donde se ejecuta lint-staged ) a las tareas. El valor predeterminado es false .--shell : De forma predeterminada, los comandos linter se analizarán para determinar su velocidad y seguridad. Esto tiene el efecto secundario de que es posible que los scripts de shell habituales no funcionen como se esperaba. Puede omitir el análisis de comandos con esta opción. Para usar un shell específico, use una ruta como --shell "/bin/bash" .--verbose : muestra el resultado de la tarea incluso cuando las tareas se realizan correctamente. De forma predeterminada, solo se muestra la salida fallida. Lint-staged se puede configurar de muchas maneras:
lint-staged en su package.json o package.yaml.lintstagedrc en formato JSON o YML, o puede ser explícito con la extensión del archivo:.lintstagedrc.json.lintstagedrc.yaml.lintstagedrc.yml.lintstagedrc.mjs o lint-staged.config.mjs en formato ESMexport default { ... }.lintstagedrc.cjs o lint-staged.config.cjs en formato CommonJSmodule.exports = { ... }lint-staged.config.js o .lintstagedrc.js en formato ESM o CommonJS, dependiendo de si el package.json de su proyecto contiene la opción "type": "module" o no.--config o -cLa configuración debe ser un objeto donde cada valor sea un comando a ejecutar y su clave sea un patrón global a usar para este comando. Este paquete utiliza micromatch para patrones globales. Los archivos JavaScript también pueden exportar configuración avanzada como función. Consulte Uso de archivos de configuración JS para obtener más información.
También puede colocar varios archivos de configuración en diferentes directorios dentro de un proyecto. Para un archivo preparado determinado, siempre se utilizará el archivo de configuración más cercano. Consulte "¿Cómo utilizar lint-staged en un monorepo de paquetes múltiples?" para más información y un ejemplo.
package.json : {
"lint-staged" : {
"*" : " your-cmd "
}
}.lintstagedrc {
"*" : " your-cmd "
} Esta configuración ejecutará your-cmd con la lista de archivos preparados actualmente pasados como argumentos.
Entonces, considerando que hiciste git add file1.ext file2.ext , lint-staged ejecutará el siguiente comando:
your-cmd file1.ext file2.ext
De forma predeterminada , lint-staged ejecutará las tareas configuradas simultáneamente. Esto significa que para cada globo, todos los comandos se iniciarán al mismo tiempo. Con la siguiente configuración, tanto eslint como prettier se ejecutarán al mismo tiempo:
{
"*.ts" : " eslint " ,
"*.md" : " prettier --list-different "
} Por lo general, esto no es un problema ya que los globos no se superponen y los comandos no realizan cambios en los archivos, sino que solo informan posibles errores (anulando la confirmación de git). Si desea ejecutar varios comandos para el mismo conjunto de archivos, puede utilizar la sintaxis de matriz para asegurarse de que los comandos se ejecuten en orden. En el siguiente ejemplo, prettier se ejecutará para ambos globs y, además, eslint se ejecutará para los archivos *.ts posteriores . Ambos conjuntos de comandos (para cada global) todavía se inician al mismo tiempo (pero no se superponen).
{
"*.ts" : [ " prettier --list-different " , " eslint " ],
"*.md" : " prettier --list-different "
} Preste especial atención cuando los globos configurados se superpongan y las tareas realicen modificaciones en los archivos. Por ejemplo, en esta configuración, prettier y eslint podrían intentar realizar cambios en el mismo archivo *.ts al mismo tiempo, provocando una condición de carrera :
{
"*" : " prettier --write " ,
"*.ts" : " eslint --fix "
}Puedes resolverlo usando el patrón de negación y la sintaxis de matriz:
{
"!(*.ts)" : " prettier --write " ,
"*.ts" : [ " eslint --fix " , " prettier --write " ]
}Otro ejemplo en el que las tareas realizan ediciones en archivos y los globos coinciden con varios archivos pero no se superponen:
{
"*.css" : [ " stylelint --fix " , " prettier --write " ],
"*.{js,jsx}" : [ " eslint --fix " , " prettier --write " ],
"!(*.css|*.js|*.jsx)" : [ " prettier --write " ]
} O, si es necesario, puede limitar la simultaneidad usando --concurrent <number> o deshabilitarla por completo con --concurrent false .
Los comandos de Linter funcionan en un subconjunto de todos los archivos preparados, definidos por un patrón global . lint-staged utiliza micromatch para hacer coincidir archivos con las siguientes reglas:
/ ), se habilitará la opción matchBase de micromatch, de modo que los globos coincidan con el nombre base de un archivo independientemente del directorio:"*.js" coincidirá con todos los archivos JS, como /test.js y /foo/bar/test.js"!(*test).js" coincidirá con todos los archivos JS, excepto aquellos que terminan en test.js , por lo que foo.js pero no foo.test.js"!(*.css|*.js)" coincidirá con todos los archivos excepto los archivos CSS y JS/ ), también coincidirá con las rutas:"./*.js" coincidirá con todos los archivos JS en la raíz del repositorio de git, por lo que /test.js pero no /foo/bar/test.js"foo/**/*.js" coincidirá con todos los archivos JS dentro del directorio /foo , por lo que /foo/bar/test.js pero no /test.jsAl hacer coincidir, lint-staged hará lo siguiente
NOTA: lint-staged pasará rutas absolutas a los linters para evitar confusiones en caso de que se ejecuten en un directorio de trabajo diferente (es decir, cuando su directorio .git no es el mismo que su directorio package.json ).
Consulte también ¿Cómo utilizar lint-staged en un monorepo de paquetes múltiples?
El concepto de lint-staged es ejecutar tareas linter configuradas (u otras tareas) en archivos preparados en git. lint-staged siempre pasará una lista de todos los archivos preparados a la tarea, e ignorar cualquier archivo debe configurarse en la propia tarea.
Considere un proyecto que utilice prettier para mantener el formato del código coherente en todos los archivos. El proyecto también almacena bibliotecas de proveedores externos minimizadas en el directorio vendor/ . Para evitar que prettier arroje errores en estos archivos, el directorio del proveedor debe agregarse a la configuración ignorada de Prettier, el archivo .prettierignore . Ejecutando npx prettier . ignorará todo el directorio de proveedores y no arrojará errores. Cuando se agrega lint-staged al proyecto y se configura para ejecutarse de forma más bonita, prettier ignorará todos los archivos modificados y preparados en el directorio del proveedor, aunque los reciba como entrada.
En escenarios avanzados, donde es imposible configurar la tarea linter en sí para ignorar archivos, pero lint-staged aún debe ignorar algunos archivos preparados, es posible filtrar las rutas de archivos antes de pasarlas a las tareas utilizando la sintaxis de la función. Consulte Ejemplo: ignorar archivos de la coincidencia.
Se admiten todos los ejecutables instalados local o globalmente a través de npm , así como cualquier ejecutable desde su $PATH.
Se desaconseja el uso de scripts instalados globalmente, ya que lint-staged puede no funcionar para alguien que no lo tenga instalado.
lint-staged usa execa para localizar scripts instalados localmente. Entonces en tu .lintstagedrc puedes escribir:
{
"*.js" : " eslint --fix "
} Esto dará como resultado la ejecución eslint --fix file-1.js file-2.js , cuando haya preparado los archivos file-1.js , file-2.js y README.md .
Pase argumentos a sus comandos separados por espacios como lo haría en el shell. Vea los ejemplos a continuación.
Puede ejecutar varios comandos en una secuencia en cada globo. Para hacerlo, pase una serie de comandos en lugar de uno solo. Esto es útil para ejecutar herramientas de formato automático como eslint --fix o stylefmt pero puede usarse para cualquier secuencia arbitraria.
Por ejemplo:
{
"*.js" : [ " eslint " , " prettier --write " ]
} Va a ejecutar eslint y si sale con el código 0 , ejecutará prettier --write en todos los archivos *.js preparados.
Esto dará como resultado la ejecución eslint file-1.js file-2.js en etapas de lint , cuando haya preparado los archivos file-1.js , file-2.js y README.md , y si pasa, prettier --write file-1.js file-2.js .
Escribir el archivo de configuración en JavaScript es la forma más poderosa de configurar lint-staged ( lint-staged.config.js , similar o pasado a través de --config ). Desde el archivo de configuración, puede exportar una sola función o un objeto.
Si el valor exports es una función, recibirá una matriz de todos los nombres de archivos preparados. Luego puede crear sus propios comparadores para los archivos y devolver una cadena de comando o una matriz de cadenas de comando. Estas cadenas se consideran completas y deben incluir los argumentos del nombre del archivo, si así lo desea.
Si el valor exports es un objeto, sus claves deben ser coincidencias globales (como en el formato de configuración normal que no es js). Los valores pueden ser como en la configuración normal o funciones individuales como se describe anteriormente. En lugar de recibir todos los archivos coincidentes, las funciones en el objeto exportado solo recibirán los archivos preparados que coincidan con la clave global correspondiente.
Para resumir, de forma predeterminada, lint-staged agrega automáticamente la lista de archivos preparados coincidentes a su comando, pero al compilar el comando usando funciones JS se espera que lo haga manualmente. Por ejemplo:
export default {
'*.js' : ( stagedFiles ) => [ `eslint .` , `prettier --write ${ stagedFiles . join ( ' ' ) } ` ] ,
} Esto dará como resultado la primera ejecución de eslint en etapas de pelusa eslint . (que coincide con todos los archivos), y si pasa, prettier --write file-1.js file-2.js , cuando hayas preparado los archivos file-1.js , file-2.js y README.md .
La función también puede ser asíncrona:
( 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 en cambios en archivos TypeScript, pero no pase ningún argumento de nombre de archivo // 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 ( ' ' ) } ` ,
}Es mejor usar la configuración basada en funciones (vista arriba), si su caso de uso es este.
// 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 por alguna razón desea ignorar archivos de la coincidencia global, puede usar 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 ( ' ' ) } `
} ,
} Tenga en cuenta que, en la mayoría de los casos, los globos pueden lograr el mismo efecto. Para el ejemplo anterior, un globo coincidente sería !(*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 ( ' ' ) } `
} ,
} Herramientas como Prettier, ESLint/TSLint o stylelint pueden reformatear su código de acuerdo con una configuración apropiada ejecutando prettier --write / eslint --fix / tslint --fix / stylelint --fix . Lint-staged agregará automáticamente cualquier modificación a la confirmación siempre que no haya errores.
{
"*.js" : " prettier --write "
} Antes de la versión 10, las tareas tenían que incluir manualmente git add como paso final. Este comportamiento se ha integrado en el propio lint-staged para evitar condiciones de carrera con múltiples tareas editando los mismos archivos. Si lint-staged detecta git add en configuraciones de tareas, mostrará una advertencia en la consola. Elimine git add de su configuración después de la actualización.
Todos los ejemplos suponen que ya configuró lint-staged en el archivo package.json y husky en su propio archivo de configuración.
{
"name" : " My project " ,
"version" : " 0.1.0 " ,
"scripts" : {
"my-custom-script" : " linter --arg1 --arg2 "
},
"lint-staged" : {}
} En .husky/pre-commit
# .husky/pre-commit
npx lint-stagedNota: no pasamos una ruta como argumento para los corredores. Esto es importante ya que lint-staged lo hará por usted.
*.js y *.jsx ejecutándose como un gancho de confirmación previa{
"*.{js,jsx}" : " eslint "
}--fix y agregue para confirmar{
"*.js" : " eslint --fix "
} Esto ejecutará eslint --fix y agregará cambios automáticamente a la confirmación.
Si desea reutilizar un script npm definido en su paquete.json:
{
"*.js" : " npm run my-custom-script -- "
}Lo siguiente es equivalente:
{
"*.js" : " linter --arg1 --arg2 "
} Los comandos de Linting no admiten la convención de shell de expandir variables de entorno. Para habilitar la convención usted mismo, utilice una herramienta como cross-env .
Por ejemplo, aquí se ejecuta jest en todos los archivos .js con la variable NODE_ENV configurada en "test" :
{
"*.js" : [ " cross-env NODE_ENV=test jest --bail --findRelatedTests " ]
}prettier para cualquier formato que admita Prettier{
"*" : " prettier --ignore-unknown --write "
}prettier para JavaScript, TypeScript, Markdown, HTML o 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 es una herramienta CLI diseñada para uso lint-staged con valores predeterminados sensatos.
Vea más en esta publicación de blog para conocer los beneficios de este enfoque.
{
"*.{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 introdujo un cambio en los enlaces donde ya no se ejecutaban en el TTY original. Esto se solucionó en 2.37.0:
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.37.0.txt
- En Git 2.36 renovamos la forma en que se invocan los ganchos. Un cambio que es visible para el usuario final es que la salida de un gancho ya no está directamente conectada a la salida estándar de "git" que genera el gancho, lo cual se notó después del lanzamiento. Esto se está corrigiendo. (fusione a082345372 ab/hooks-regression-fix más adelante para mantener).
Si actualizar Git no ayuda, puedes intentar redirigir manualmente la salida en tu enlace de Git; Por ejemplo:
# .husky/pre-commit
if sh -c " : >/dev/tty " > /dev/null 2> /dev/null ; then exec > /dev/tty 2>&1 ; fi
npx lint-stagedFuente: typicode/husky#968 (comentario)
lint-staged a través del nodo?¡Sí!
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 )
} Los parámetros de lintStaged son equivalentes a sus homólogos CLI:
const success = await lintStaged ( {
allowEmpty : false ,
c
