lint staged
v15.2.10
준비된 git 파일에 대해 linter를 실행하고 ? 코드 베이스에 빠져보세요!
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은 코드를 커밋하기 전에 실행할 때 더 적합합니다. 이렇게 하면 저장소에 오류가 발생하지 않도록 하고 코드 스타일을 적용할 수 있습니다. 그러나 전체 프로젝트에서 Lint 프로세스를 실행하는 것은 느리고 Linting 결과는 관련성이 없을 수 있습니다. 궁극적으로 커밋될 파일만 린트하려고 합니다.
이 프로젝트에는 지정된 glob 패턴으로 필터링된 준비된 파일 목록을 인수로 사용하여 임의의 셸 작업을 실행하는 스크립트가 포함되어 있습니다.
dotnet-format 및 lint-staged 로 CSharp를 더욱 아름답게 만드세요.작성하신 경우 링크와 함께 PR을 제출해 주세요!
권장되는 방식으로 lint-staged를 설치하려면 다음을 수행해야 합니다.
npm install --save-dev lint-stagedpre-commit git 후크 설정{ "*.js": "eslint" } 이 설정을 팀과 공유하려면 package.json 및 .husky 에 대한 변경 사항을 커밋하는 것을 잊지 마세요!
이제 몇 가지 파일을 변경하고 git add 또는 git add --patch 일부 파일을 커밋에 패치하고 git commit 을 시도합니다.
자세한 내용은 예제 및 구성을 참조하세요.
릴리스를 참조하세요.
v15.0.0 lint-staged 는 더 이상 Node.js 16을 지원하지 않습니다. Node.js 버전을 18.12.0 이상으로 업그레이드하세요. v14.0.0 lint-staged 는 더 이상 Node.js 14를 지원하지 않습니다. Node.js 버전을 16.14.0 이상으로 업그레이드하세요. v13.0.0 lint-staged 는 더 이상 Node.js 12를 지원하지 않습니다. Node.js 버전을 최소 14.13.1 또는 16.0.0 이상으로 업그레이드하세요.v14.0.0 의 코드를 포함하여 버전 v13.3.0 잘못 릴리스되었습니다. 이는 v14 의 주요 변경 사항이 마지막 v13 버전인 v13.3.0 에도 포함되어 있음을 의미합니다. v12.0.0 lint-staged는 순수 ESM 모듈이므로 Node.js 버전이 12.20.0 , 14.13.1 또는 16.0.0 이상인지 확인하세요. 여기 공식 Node.js 문서 사이트에서 ESM 모듈에 대해 자세히 알아보세요. v10.0.0 부터 원래 준비된 파일에 대한 새로운 수정 사항이 자동으로 커밋에 추가됩니다. 이전에 작업에 git add 단계가 포함되어 있었다면 이를 제거하세요. 동시에 여러 Git 작업을 실행하려고 하면 일반적으로 오류가 발생하므로 자동 동작을 사용하면 경쟁 조건이 줄어듭니다.v10.0.0 부터 lint-staged는 git stash를 사용하여 속도를 향상하고 실행 중 백업을 제공합니다. git stash에는 최소한 초기 커밋이 필요하므로 빈 저장소에서 lint-staged를 실행하면 안 됩니다.v10.0.0 부터 lint-staged에는 Node.js 버전 10.13.0 이상이 필요합니다.v10.0.0 부터 lint-staged는 linter 작업이 모든 단계적 변경 사항을 취소하는 경우 커밋을 중단합니다. 빈 커밋 생성을 허용하려면 --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 : 기본적으로 linter 작업이 모든 단계적 변경 사항을 실행 취소하면 lint-staged는 오류와 함께 종료되고 커밋을 중단합니다. 빈 Git 커밋 생성을 허용하려면 이 플래그를 사용하세요.--concurrent [number|boolean] : lint-staged로 실행되는 작업의 동시성을 제어합니다. 참고 : 이는 하위 작업의 동시성에 영향을 주지 않습니다(항상 순차적으로 실행됩니다). 가능한 값은 다음과 같습니다.false : 모든 작업을 순차적으로 실행true (기본값) : 무한 동시성. 가능한 한 많은 작업을 병렬로 실행합니다.{number} : 지정된 수의 작업을 병렬로 실행합니다. 여기서 1 false 에 해당합니다.--config [path] : 구성 파일 또는 npm 패키지 이름의 경로를 수동으로 지정합니다. 참고: lint-staged를 사용하면 구성 파일 검색을 수행하지 않고 지정된 파일을 찾을 수 없으면 오류를 인쇄합니다. 파일 이름으로 '-'가 제공되면 stdin에서 구성을 읽어 cat my-config.json | npx lint-staged --config - .--cwd [path] : 기본적으로 작업은 현재 작업 디렉터리에서 실행됩니다. 이를 재정의하려면 --cwd some/directory 사용하십시오. 경로는 현재 작업 디렉터리에 대한 절대 경로이거나 상대 경로일 수 있습니다.--debug : 디버그 모드에서 실행됩니다. 설정되면 다음을 수행합니다.$DEBUG 환경 변수를 lint-staged* 로 설정하여 활성화할 수도 있습니다.listr2 에 대해 verbose 렌더러를 사용합니다. 이로 인해 기본(미적, 동적) 출력 대신 터미널에 무색 직렬 출력이 발생합니다. ( verbose 렌더러는 TERM=dumb 또는 NODE_ENV=test 환경 변수를 설정하여 활성화할 수도 있습니다)--diff : 기본적으로 린터는 git diff --staged 에서 생성된 git에 준비된 모든 파일에 대해 필터링됩니다. 이 옵션을 사용하면 임의의 개정판으로 --staged 플래그를 재정의할 수 있습니다. 예를 들어 두 브랜치 간에 변경된 파일 목록을 얻으려면 --diff="branch1...branch2" 사용하세요. git diff 및 gitrevisions에 대한 자세한 내용을 읽을 수도 있습니다. 이 옵션은 --no-stash 도 의미합니다.--diff-filter : 기본적으로 추가 , 복사 , 수정 또는 이름이 변경된 파일만 포함됩니다. 이 플래그를 사용하여 기본 ACMR 값을 추가 ( A ), 복사 ( C ), 삭제 ( D ), 수정 ( M ), 이름 변경 ( R ), 유형 변경 ( T ), 병합 해제 ( U ), 알 수 없는 항목 으로 재정의합니다. ( X ) 또는 페어링이 끊어졌습니다 ( B ). --diff-filter에 대한 git diff 문서도 참조하세요.--max-arg-length : 긴 명령(많은 파일)은 현재 쉘이 이를 처리할 수 없음을 감지하면 자동으로 여러 청크로 분할됩니다. 생성된 명령 문자열의 최대 길이를 대체하려면 이 플래그를 사용하십시오.--no-stash : 기본적으로 작업을 실행하기 전에 백업 숨김이 생성되며 오류가 발생할 경우 모든 작업 수정 사항이 되돌려집니다. 이 옵션은 스태시 생성을 비활성화하고 대신 커밋을 중단할 때 인덱스에 모든 수정 사항을 남겨 둡니다. --stash 로 다시 활성화할 수 있습니다. 이 옵션은 --no-hide-partially-staged 도 의미합니다.--no-hide-partially-staged : 기본적으로 부분적으로 준비된 파일의 unstaged 변경 사항은 숨겨집니다. 이 옵션은 이 동작을 비활성화하고 부분적으로 준비된 파일에 모든 준비되지 않은 변경 사항을 포함합니다. --hide-partially-staged 사용하여 다시 활성화할 수 있습니다.--quiet : 작업을 제외한 모든 CLI 출력을 억제합니다.--relative : process.cwd() ( lint-staged 실행되는 위치)에 상대적인 파일 경로를 작업에 전달합니다. 기본값은 false 입니다.--shell : 기본적으로 속도와 보안을 위해 linter 명령이 구문 분석됩니다. 이는 일반 쉘 스크립트가 예상대로 작동하지 않을 수 있다는 부작용이 있습니다. 이 옵션을 사용하면 명령 구문 분석을 건너뛸 수 있습니다. 특정 셸을 사용하려면 --shell "/bin/bash" 와 같은 경로를 사용하세요.--verbose : 작업이 성공하더라도 작업 출력을 표시합니다. 기본적으로 실패한 출력만 표시됩니다. Lint-staged는 다양한 방법으로 구성할 수 있습니다.
package.json 또는 package.yaml 의 lint-staged 개체.lintstagedrc 파일을 JSON 또는 YML 형식으로 지정하거나 파일 확장자를 명시적으로 지정할 수 있습니다..lintstagedrc.json.lintstagedrc.yaml.lintstagedrc.yml.lintstagedrc.mjs 또는 lint-staged.config.mjs 파일export default { ... }.lintstagedrc.cjs 또는 lint-staged.config.cjs 파일module.exports = { ... }"type": "module" 옵션이 포함되어 있는지 여부에 따라 ESM 또는 CommonJS 형식의 lint-staged.config.js 또는 .lintstagedrc.js .--config 또는 -c 플래그를 사용하여 구성 파일을 전달합니다.구성은 각 값이 실행할 명령이고 해당 키가 이 명령에 사용할 글로벌 패턴인 개체여야 합니다. 이 패키지는 글로브 패턴에 마이크로매치를 사용합니다. JavaScript 파일은 고급 구성을 함수로 내보낼 수도 있습니다. 자세한 내용은 JS 구성 파일 사용을 참조하세요.
프로젝트 내의 서로 다른 디렉터리에 여러 구성 파일을 배치할 수도 있습니다. 지정된 준비된 파일의 경우 항상 가장 가까운 구성 파일이 사용됩니다. "다중 패키지 모노레포에서 lint-staged 사용하는 방법은 무엇입니까?"를 참조하세요. 자세한 정보와 예를 보려면.
package.json 예: {
"lint-staged" : {
"*" : " your-cmd "
}
}.lintstagedrc 예 {
"*" : " your-cmd "
} 이 구성은 현재 준비된 파일 목록을 인수로 전달하여 your-cmd 실행합니다.
따라서 git add file1.ext file2.ext 수행한 것을 고려하면 lint-staged는 다음 명령을 실행합니다.
your-cmd file1.ext file2.ext
기본적으로 lint-staged는 구성된 작업을 동시에 실행합니다. 이는 모든 glob에 대해 모든 명령이 동시에 시작된다는 것을 의미합니다. 다음 구성을 사용하면 eslint 와 prettier 동시에 실행됩니다.
{
"*.ts" : " eslint " ,
"*.md" : " prettier --list-different "
} 일반적으로 glob이 겹치지 않고 명령이 파일을 변경하지 않고 가능한 오류만 보고하므로(git 커밋 중단) 이는 문제가 되지 않습니다. 동일한 파일 세트에 대해 여러 명령을 실행하려는 경우 배열 구문을 사용하여 명령이 순서대로 실행되는지 확인할 수 있습니다. 다음 예에서 prettier 두 glob 모두에 대해 실행되고 추가로 eslint 그 이후의 *.ts 파일에 대해 실행됩니다. 두 명령 세트(각 glob에 대해)는 여전히 동시에 시작됩니다(그러나 겹치지는 않습니다).
{
"*.ts" : [ " prettier --list-different " , " eslint " ],
"*.md" : " prettier --list-different "
} 구성된 글로브가 겹치고 작업이 파일을 편집하는 경우 특히 주의하십시오. 예를 들어, 이 구성에서는 prettier 와 eslint 동시에 동일한 *.ts 파일을 변경하려고 시도하여 경쟁 조건이 발생할 수 있습니다.
{
"*" : " prettier --write " ,
"*.ts" : " eslint --fix "
}부정 패턴과 배열 구문을 사용하여 이 문제를 해결할 수 있습니다.
{
"!(*.ts)" : " prettier --write " ,
"*.ts" : [ " eslint --fix " , " prettier --write " ]
}작업이 파일을 편집하고 glob이 여러 파일과 일치하지만 겹치지 않는 또 다른 예:
{
"*.css" : [ " stylelint --fix " , " prettier --write " ],
"*.{js,jsx}" : [ " eslint --fix " , " prettier --write " ],
"!(*.css|*.js|*.jsx)" : [ " prettier --write " ]
} 또는 필요한 경우 --concurrent <number> 사용하여 동시성을 제한하거나 --concurrent false 사용하여 완전히 비활성화할 수 있습니다.
Linter 명령은 glob 패턴 으로 정의된 모든 스테이지 파일의 하위 집합에서 작동합니다. lint-staged는 다음 규칙에 따라 파일을 일치시키기 위해 마이크로매치를 사용합니다.
/ )가 포함되어 있지 않으면 micromatch의 matchBase 옵션이 활성화되므로 glob은 디렉터리에 관계없이 파일의 기본 이름과 일치합니다."*.js" /test.js 및 /foo/bar/test.js 와 같은 모든 JS 파일과 일치합니다."!(*test).js" test.js 로 끝나는 파일을 제외한 모든 JS 파일과 일치하므로 foo.js 는 foo.test.js 와 일치하지 않습니다."!(*.css|*.js)" CSS 및 JS 파일을 제외한 모든 파일과 일치합니다./ )가 포함되어 있으면 경로에도 일치합니다."./*.js" git repo 루트의 모든 JS 파일과 일치하므로 /test.js 일치하지만 /foo/bar/test.js 일치하지 않습니다."foo/**/*.js" /foo 디렉토리 내의 모든 JS 파일과 일치하므로 /foo/bar/test.js 일치하지만 /test.js 일치하지 않습니다.일치 시 lint-staged는 다음을 수행합니다.
참고: lint-staged 다른 작업 디렉터리에서 실행되는 경우(예: .git 디렉터리가 package.json 디렉터리와 동일하지 않은 경우) 혼동을 피하기 위해 linter에 절대 경로를 전달합니다.
다중 패키지 모노레포에서 lint-staged 사용하는 방법도 참조하세요.
lint-staged 의 개념은 git에 준비된 파일에 대해 구성된 linter 작업(또는 기타 작업)을 실행하는 것입니다. lint-staged 항상 준비된 모든 파일 목록을 작업에 전달하며 모든 파일을 무시하도록 작업 자체에서 구성해야 합니다.
모든 파일에서 코드 형식을 일관되게 유지하기 위해 prettier 사용하는 프로젝트를 고려해 보세요. 또한 이 프로젝트는 축소된 타사 공급업체 라이브러리를 vendor/ 디렉터리에 저장합니다. prettier 이러한 파일에서 오류를 발생시키지 않도록 하려면 공급업체 디렉터리를 Prettier의 무시 구성인 .prettierignore 파일에 추가해야 합니다. npx prettier . 오류가 발생하지 않고 전체 공급업체 디렉터리를 무시합니다. lint-staged 프로젝트에 추가되고 더 예쁘게 실행되도록 구성되면 공급업체 디렉터리에 있는 모든 수정 및 스테이징된 파일은 입력으로 수신되더라도 prettier에서 무시됩니다.
파일을 무시하도록 linter 작업 자체를 구성하는 것은 불가능하지만 일부 준비된 파일은 lint-staged 에서 여전히 무시해야 하는 고급 시나리오에서는 함수 구문을 사용하여 파일 경로를 작업에 전달하기 전에 필터링할 수 있습니다. 예: 일치에서 파일 무시를 참조하세요.
$PATH의 모든 실행 파일은 물론 npm 통해 로컬 또는 전역으로 설치된 모든 실행 파일이 지원됩니다.
전역적으로 설치된 스크립트를 사용하는 것은 권장되지 않습니다. Lint-staged가 설치되어 있지 않은 사람에게는 작동하지 않을 수 있기 때문입니다.
lint-staged execa를 사용하여 로컬에 설치된 스크립트를 찾습니다. 따라서 .lintstagedrc 에 다음과 같이 작성할 수 있습니다.
{
"*.js" : " eslint --fix "
} 그러면 file-1.js , file-2.js 및 README.md 파일이 준비된 경우 eslint --fix file-1.js file-2.js lint-staged 실행됩니다.
셸에서와 마찬가지로 공백으로 구분하여 명령에 인수를 전달합니다. 아래 예를 참조하세요.
모든 glob에서 여러 명령을 순서대로 실행할 수 있습니다. 이렇게 하려면 단일 명령 대신 명령 배열을 전달하십시오. 이는 eslint --fix 또는 stylefmt 와 같은 자동 서식 지정 도구를 실행하는 데 유용하지만 임의의 시퀀스에 사용할 수 있습니다.
예를 들어:
{
"*.js" : [ " eslint " , " prettier --write " ]
} eslint 실행하고 코드가 0 으로 종료되면 모든 준비된 *.js 파일에 대해 prettier --write 실행합니다.
이렇게 하면 file-1.js , file-2.js 및 README.md 파일을 스테이징한 경우 eslint file-1.js file-2.js lint-staged 로 실행하고, 통과하면 prettier --write file-1.js file-2.js 실행하게 됩니다. prettier --write file-1.js file-2.js .
JavaScript로 구성 파일을 작성하는 것은 lint-staged( lint-staged.config.js , 유사하거나 --config 통해 전달됨)를 구성하는 가장 강력한 방법입니다. 구성 파일에서 단일 함수 또는 개체를 내보낼 수 있습니다.
exports 값이 함수인 경우 모든 준비된 파일 이름의 배열을 받습니다. 그런 다음 파일에 대한 자체 일치자를 작성하고 명령 문자열 또는 명령 문자열 배열을 반환할 수 있습니다. 이러한 문자열은 완전한 것으로 간주되며 원하는 경우 파일 이름 인수를 포함해야 합니다.
exports 값이 객체인 경우 해당 키는 전역 일치여야 합니다(예: 일반적인 비JS 구성 형식). 값은 일반 구성과 같을 수도 있고 위에 설명된 개별 기능과 같을 수도 있습니다. 일치하는 모든 파일을 수신하는 대신 내보낸 객체의 함수는 해당 glob 키와 일치하는 준비된 파일만 수신합니다.
요약하자면, 기본적으로 lint-staged는 일치하는 스테이지 파일 목록을 명령에 자동으로 추가하지만 JS 기능을 사용하여 명령을 빌드할 때는 이 작업을 수동으로 수행해야 합니다. 예를 들어:
export default {
'*.js' : ( stagedFiles ) => [ `eslint .` , `prettier --write ${ stagedFiles . join ( ' ' ) } ` ] ,
} 그러면 lint-staged 첫 번째 실행 eslint . ( 모든 파일과 일치) 통과하면 file-1.js , file-2.js 및 README.md 파일을 준비한 경우 prettier --write file-1.js file-2.js .
이 함수는 비동기식일 수도 있습니다.
( 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 실행하지만 파일 이름 인수를 전달하지 마세요. // 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 ( ' ' ) } ` ,
}사용 사례가 이와 같은 경우에는 함수 기반 구성(위 참조)을 사용하는 것이 더 좋습니다.
// 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 ( ' ' ) } ` ]
} ,
} 어떤 이유로 glob 일치에서 파일을 무시하려면 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 ( ' ' ) } `
} ,
} 대부분의 경우 glob은 동일한 효과를 얻을 수 있습니다. 위의 예에서 일치하는 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 ( ' ' ) } `
} ,
} Prettier, ESLint/TSLint 또는 stylelint와 같은 도구는 prettier --write / eslint --fix / tslint --fix / stylelint --fix 실행하여 적절한 구성에 따라 코드 형식을 다시 지정할 수 있습니다. Lint-staged는 오류가 없는 한 커밋에 수정 사항을 자동으로 추가합니다.
{
"*.js" : " prettier --write "
} 버전 10 이전에는 작업의 최종 단계에 git add 수동으로 포함해야 했습니다. 동일한 파일을 편집하는 여러 작업으로 인한 경쟁 조건을 방지하기 위해 이 동작은 Lint-staged 자체에 통합되었습니다. lint-staged가 작업 구성에서 git add 감지하면 콘솔에 경고가 표시됩니다. 업그레이드한 후 구성에서 git add 제거하세요.
모든 예에서는 package.json 파일에 lint-staged를 이미 설정하고 자체 구성 파일에 husky를 설정했다고 가정합니다.
{
"name" : " My project " ,
"version" : " 0.1.0 " ,
"scripts" : {
"my-custom-script" : " linter --arg1 --arg2 "
},
"lint-staged" : {}
} .husky/pre-commit 에서
# .husky/pre-commit
npx lint-staged참고: 우리는 실행자에 대한 인수로 경로를 전달하지 않습니다. lint-staged가 이 작업을 수행하므로 이는 중요합니다.
*.js 및 *.jsx 에 대한 기본 매개변수가 있는 ESLint{
"*.{js,jsx}" : " eslint "
}--fix 사용하여 코드 스타일을 자동으로 수정하고 커밋에 추가{
"*.js" : " eslint --fix "
} 그러면 eslint --fix 실행되고 자동으로 커밋에 변경 사항이 추가됩니다.
package.json에 정의된 npm 스크립트를 재사용하려면 다음을 수행하세요.
{
"*.js" : " npm run my-custom-script -- "
}다음은 동일합니다:
{
"*.js" : " linter --arg1 --arg2 "
} 린팅 명령은 환경 변수 확장의 쉘 규칙을 지원 하지 않습니다 . 규칙을 직접 활성화하려면 cross-env 와 같은 도구를 사용하세요.
예를 들어, 다음은 NODE_ENV 변수가 "test" 로 설정된 모든 .js 파일에서 실행되는 jest 입니다.
{
"*.js" : [ " cross-env NODE_ENV=test jest --bail --findRelatedTests " ]
}prettier 수정합니다.{
"*" : " prettier --ignore-unknown --write "
}prettier 자동으로 수정합니다.{
"*.{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-staged 에 대한 추가 정보imagemin-lint-staged는 적절한 기본값을 사용하여 lint-staged 사용을 위해 설계된 CLI 도구입니다.
이 접근 방식의 이점에 대한 자세한 내용은 이 블로그 게시물을 참조하세요.
{
"*.{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에서는 원래 TTY에서 더 이상 실행되지 않는 후크에 대한 변경 사항을 도입했습니다. 이 문제는 2.37.0에서 수정되었습니다.
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.37.0.txt
- Git 2.36에서는 후크가 호출되는 방식을 개선했습니다. 최종 사용자가 볼 수 있는 한 가지 변경 사항은 후크의 출력이 릴리스 이후에 발견된 후크를 생성하는 "git"의 표준 출력에 더 이상 직접 연결되지 않는다는 것입니다. 이 부분은 수정되고 있습니다. (나중에 a082345372 ab/hooks-regression-fix를 유지 관리에 병합)
Git 업데이트가 도움이 되지 않으면 Git 후크에서 출력을 수동으로 리디렉션할 수 있습니다. 예를 들어:
# .husky/pre-commit
if sh -c " : >/dev/tty " > /dev/null 2> /dev/null ; then exec > /dev/tty 2>&1 ; fi
npx lint-staged출처: typicode/husky#968(댓글)
lint-staged 사용할 수 있나요?예!
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 )
} lintStaged 에 대한 매개변수는 CLI 대응 매개변수와 동일합니다.
const success = await lintStaged ( {
allowEmpty : false ,
c
