lint staged
v15.2.10
ステージングされた git ファイルに対してリンターを実行し、?コードベースに滑り込みましょう！
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...
lint は、コードをコミットする前に実行するとより意味があります。そうすることで、リポジトリにエラーが入らないようにし、コード スタイルを強制することができます。ただし、プロジェクト全体で lint プロセスを実行すると時間がかかり、lint の結果が無関係になる可能性があります。最終的には、コミットされるファイルのみ lint を実行する必要があります。
このプロジェクトには、ステージングされたファイルのリストを引数として使用し、指定された glob パターンでフィルターされた任意のシェル タスクを実行するスクリプトが含まれています。
dotnet-formatとlint-stagedで CSharp をさらに美しくする作成した場合は、そのリンクを付けて PR を送信してください。
推奨される方法でlint ステージングをインストールするには、次のことを行う必要があります。
npm install --save-dev lint-stagedpre-commit git フックをセットアップする{ "*.js": "eslint" }ステージングされたすべての 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以降にアップグレードしてください。v13.3.0は、バージョンv14.0.0のコードを含めて誤ってリリースされました。これは、 v14の重大な変更が、最後にリリースされたv13バージョンであるv13.3.0にも含まれていることを意味します。 v12.0.0 lint-staged は純粋な ESM モジュールであるため、Node.js のバージョンが少なくとも12.20.0 、 14.13.1 、または16.0.0であることを確認してください。 ESM モジュールの詳細については、こちらの公式 Node.js ドキュメント サイトをご覧ください。 v10.0.0以降、最初にステージングされたファイルに対する新しい変更は自動的にコミットに追加されます。タスクに以前git addステップが含まれていた場合は、これを削除してください。複数の git 操作を同時に実行しようとすると通常はエラーが発生するため、自動動作により競合状態が少なくなります。v10.0.0以降、lint-staged は git stash を使用して速度を向上させ、実行中にバックアップを提供します。 git stash には少なくとも初期コミットが必要なため、空のリポジトリで lint-staged を実行しないでください。v10.0.0以降、lint ステージングには Node.js バージョン 10.13.0 以降が必要です。v10.0.0以降、リンター タスクがすべてのステージングされた変更を元に戻す場合、lint-staged はコミットを中止します。空のコミットの作成を許可するには、 --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 : デフォルトでは、リンター タスクがステージングされたすべての変更を元に戻すと、lint-staged はエラーで終了し、コミットを中止します。このフラグを使用して、空の git コミットの作成を許可します。--concurrent [number|boolean] : lint ステージングによって実行されるタスクの同時実行性を制御します。注: これはサブタスクの同時実行性に影響しません (サブタスクは常に順番に実行されます)。可能な値は次のとおりです。false : すべてのタスクをシリアルに実行します。true (デフォルト) :無限の同時実行。できるだけ多くのタスクを並行して実行します。{number} : 指定された数のタスクを並列実行します。1 1 falseに相当します。--config [path] : 構成ファイルまたは npm パッケージ名へのパスを手動で指定します。注: lint-staged を使用すると、構成ファイルの検索が実行されず、指定されたファイルが見つからない場合はエラーが出力されます。ファイル名として「-」が指定されている場合、構成は標準入力から読み取られ、 cat my-config.json | npx lint-staged --config -のような構成内でのパイピングが可能になります。 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フラグを任意のリビジョンでオーバーライドできます。たとえば、2 つのブランチ間で変更されたファイルのリストを取得するには、 --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 : デフォルトでは、部分的にステージングされたファイルからのステージングされていない変更は非表示になります。このオプションはこの動作を無効にし、部分的にステージングされたファイルにステージングされていないすべての変更を含めます。 --hide-partially-stagedで再度有効にすることができます--quiet : タスクからの出力を除き、すべての CLI 出力を抑制します。--relative : process.cwd() ( lint-staged実行される場所) に相対的なファイルパスをタスクに渡します。デフォルトはfalseです。--shell : デフォルトでは、リンター コマンドは速度とセキュリティのために解析されます。これには、通常のシェル スクリプトが期待どおりに動作しない可能性があるという副作用があります。このオプションを使用すると、コマンドの解析をスキップできます。特定のシェルを使用するには、 --shell "/bin/bash"のようなパスを使用します。--verbose : タスクが成功した場合でもタスクの出力を表示します。デフォルトでは、失敗した出力のみが表示されます。 lint ステージングはさまざまな方法で構成できます。
package.jsonまたはpackage.yaml内のlint-stagedオブジェクト.lintstagedrcファイル、またはファイル拡張子を明示的に指定することもできます。.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フラグを使用して構成ファイルを渡します構成は、各値が実行するコマンドであり、そのキーがこのコマンドに使用する glob パターンであるオブジェクトである必要があります。このパッケージは、glob パターンに micromatch を使用します。 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 "
}グロブは重複せず、コマンドはファイルに変更を加えず、発生する可能性のあるエラー (git コミットの中止) のみを報告するため、これは通常は問題になりません。同じファイルセットに対して複数のコマンドを実行する場合は、配列構文を使用してコマンドが順番に実行されるようにすることができます。次の例では、 prettier両方の glob に対して実行され、さらにeslintその後の*.tsファイルに対して実行されます。両方のコマンド セット (グロブごと) は依然として同時に開始されます (ただし、重複はありません)。
{
"*.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 " ]
}タスクがファイルを編集し、グロブが複数のファイルに一致するが重複しない別の例:
{
"*.css" : [ " stylelint --fix " , " prettier --write " ],
"*.{js,jsx}" : [ " eslint --fix " , " prettier --write " ],
"!(*.css|*.js|*.jsx)" : [ " prettier --write " ]
}または、必要に応じて、 --concurrent <number>使用して同時実行を制限したり、 --concurrent falseを使用して同時実行を完全に無効にしたりできます。
リンター コマンドは、グロブ パターンによって定義された、ステージングされたすべてのファイルのサブセットに対して機能します。 lint-staged は、次のルールでファイルを照合するために micromatch を使用します。
/ ) が含まれていない場合、micromatch のmatchBaseオプションが有効になるため、グロブはディレクトリに関係なくファイルのベース名と一致します。"*.js" 、 /test.jsや/foo/bar/test.jsなどのすべての JS ファイルに一致します。"!(*test).js" 、 test.jsで終わるファイルを除くすべての JS ファイルに一致します。そのため、 foo.jsには一致しますが、 foo.test.jsには一致しません。"!(*.css|*.js)" CSS ファイルと JS ファイルを除くすべてのファイルに一致します。/ ) が含まれている場合は、パスにも一致します。"./*.js" git リポジトリ ルート内のすべての JS ファイルに一致するため、 /test.jsには一致しますが、 /foo/bar/test.jsには一致しません。"foo/**/*.js" 、 /fooディレクトリ内のすべての JS ファイルと一致します。つまり、 /foo/bar/test.js一致しますが、 /test.js一致しません。マッチング時に、lint-staged は次の処理を実行します。
注: lint-stagedリンターが別の作業ディレクトリで実行される場合 (つまり、 .gitディレクトリがpackage.jsonディレクトリと同じでない場合) の混乱を避けるために、リンターに絶対パスを渡します。
「マルチパッケージのモノリポジトリでlint-staged使用する方法」も参照してください。
lint-stagedの概念は、git でステージングされたファイルに対して構成されたリンター タスク (または他のタスク) を実行することです。 lint-staged常に、ステージングされたすべてのファイルのリストをタスクに渡します。ファイルを無視するようにタスク自体で設定する必要があります。
すべてのファイル間でコード形式の一貫性を保つためにprettierを使用するプロジェクトを考えてみましょう。このプロジェクトでは、縮小されたサードパーティ ベンダー ライブラリもvendor/ディレクトリに保存されます。 prettierこれらのファイルでエラーをスローしないようにするには、vendor ディレクトリを prettier の無視設定である.prettierignoreファイルに追加する必要があります。 npx prettier .はベンダー ディレクトリ全体を無視し、エラーはスローされません。 lint-stagedがプロジェクトに追加され、prettier を実行するように設定されている場合、vendor ディレクトリ内のすべての変更およびステージングされたファイルは、入力として受け取ったとしても、prettier によって無視されます。
ファイルを無視するようにリンター タスク自体を構成することは不可能だが、一部のステージングされたファイルをlint-stagedによって無視する必要がある高度なシナリオでは、関数構文を使用してファイルパスをタスクに渡す前にファイルパスをフィルターすることができます。 「例: 一致するファイルを無視する」を参照してください。
サポートされているのは、ローカルまたはnpm経由でグローバルにインストールされた実行可能ファイル、および $PATH からの実行可能ファイルです。
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 ステージングが行われます。
シェルで行う場合と同様に、スペースで区切ってコマンドに引数を渡します。以下の例を参照してください。
すべてのグロブで複数のコマンドを連続して実行できます。これを行うには、単一のコマンドではなく、一連のコマンドを渡します。これは、 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 ステージングで実行され、パスした場合は、 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値がオブジェクトの場合、そのキーは glob 一致である必要があります (通常の非 JS 構成形式と同様)。値は、通常の設定と同様にすることも、上で説明したような個々の関数のいずれかにすることができます。エクスポートされたオブジェクト内の関数は、一致したすべてのファイルを受信するのではなく、対応するグロブ キーに一致するステージングされたファイルのみを受信します。
要約すると、デフォルトでは、 lint-staged は一致するステージングされたファイルのリストをコマンドに自動的に追加しますが、JS 関数を使用してコマンドを構築する場合は、これを手動で行う必要があります。例えば：
export default {
'*.js' : ( stagedFiles ) => [ `eslint .` , `prettier --write ${ stagedFiles . join ( ' ' ) } ` ] ,
}これにより、lint ステージングされた最初の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 ( ' ' ) } ` ]
} ,
}何らかの理由で、グロブ一致からのファイルを無視したい場合は、 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 は!(*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 ステージングでは、エラーがない限り、コミットに変更が自動的に追加されます。
{
"*.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 "
}lint コマンドは、環境変数を展開するシェル規則をサポートしていません。この規則を自分で有効にするには、 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 では、フックの呼び出し方法が刷新されました。エンドユーザーに見える変更の 1 つは、フックの出力がフックを生成する「git」の標準出力に直接接続されなくなったことです。これはリリース後に認識されました。これは修正されつつあります。 (a082345372 ab/hooks-regression-fix を後で maint にマージします)。
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
