🫠

lint-stagedで実行するスクリプトになんかファイルパスが付いてて詰まってた話

2024/11/13に公開

概要

タイトル通り、「lint-stagedで実行したスクリプトの最後になんかパスついてるな〜、そのせいでスクリプト実行うまくいかないな〜」となってました。
ドキュメントをしっかり読んでれば(しっかりじゃなくてもいいかも)詰まることはなかったので、「ドキュメント読んで理解して使え」っていう自分への戒めとして記事に残しておきます。

lint-stagedとは

指定したパターンにマッチしたファイルが変更された時に実行するスクリプトを定義できます。
Git Hooksと組み合わせて、コミット前にリントを強制するみたいな使い方をします。

結論

というか結論しかありません。😄
実行するスクリプトについてたファイルパスは変更されたファイルでした。

例のところに、こう書くと、変更されたファイルがこんな感じで引数に渡されるよって書いてありました。
https://github.com/lint-staged/lint-staged?tab=readme-ov-file#lintstagedrc-example

{
  "*": "your-cmd"
}

your-cmd file1.ext file2.ext

それはそれで反省するとして、変更されたファイルを引数に入れたくない事情があったので以下のように定義ファイルにjsを使用することで対応しました。

.lintstagedrc.mjs
export default {
  'フィルタ': () => ["{実行するスクリプト}"],
}

おまけ

https://github.com/lint-staged/lint-staged?tab=readme-ov-file#why
lint-stagedの存在意義

Linting makes more sense when run before committing your code. By doing so you can ensure no errors go into the repository and enforce code style. But running a lint process on a whole project is slow, and linting results can be irrelevant. Ultimately you only want to lint files that will be committed.
This project contains a script that will run arbitrary shell tasks with a list of staged files as an argument, filtered by a specified glob pattern.
コミットする前にリントを実行すると、より意味があります。そうすることで、リポジトリにエラーが入り込むのを防ぎ、コードスタイルを強制することができます。しかし、プロジェクト全体に対してリントを実行すると時間がかかり、リントの結果が関係なくなる可能性があります。最終的には、コミットされるファイルのみをリントしたいはずです。 このプロジェクトには、指定された glob パターンでフィルタリングされた、ステージング(変更)されたファイルのリストを引数として任意のシェルタスクを実行するスクリプトが含まれています。

そもそもの目的がこれだ😇

Discussion