品質第一！JavaScriptプロジェクトでGitHubワークフローを使ってコードをlintする5つの簡単なステップ

ヴォイチェフ・バク

コードの品質は、開発プロセスにおいて、特に長期的に効率よく作業を進めたい場合には、非常に重要な部分である。アジャイル方法論全体を含め、多くのアプローチやベストプラクティスがあるが、それらのほとんどは、少なくとも6人で行われる大規模な企業プロジェクトに関連している。

どうすればいいのだろう。プロジェクトが小さいのか、それとも顧客がまだ投資する価値があるのかわからないのか？明らかに プロジェクトのMVP段階, コードスタイリングやユニットテストは最優先事項ではない。投資家は通常、優れた製品もしうまくいくなら、テストは必要ないだろう？

実は、私は ゼロからアプリを作るそもそもベストプラクティスを使わなくても。ビジネス上の事情で、投資家の予算計画と開発者の「いいとこ取り」リストの妥協点を探さざるを得ないこともあった。ありがたいことに、GitHubを使えば、コードの品質に関する一般的な問題のほとんどは数分で解決できる。

この記事では、Node.js環境でGitHubワークフローを使ってコードベースを標準化する方法を紹介する。

始める前にいくつか仮定しておこう：

NPMとLinuxコンソールに精通している。
スタイル・プリプロセッサ、モジュール・ローダー、バンドルなどの使用経験がある。
リンターが何のためにあるのか知っていて、自分のプロジェクトに使いたいと思っている。

1.典型的なJavaScriptプロジェクトの構成

のようなJSフレームワークを使用したことがある場合 Vue とReactの間には、いくつかの共通点がある：

/src ディレクトリに、すべてのJSロジックとコンポーネントを置きます、
/テスト ディレクトリを作成します、
/資産 ディレクトリにスタイルや画像などを置く。

について話しているとしても JavaScript プロジェクトではノードのようなNodeのものもあるはずです。 package.json, パッケージロック.json そして /ノードモジュール カタログをルート・ディレクトリに置く。

これらすべてのものがそれぞれの場所にある。 コンベンション.フレームワークは合理的な規約を提供するために発明されたものなので、通常は最初のデザインパターンにこだわる必要はない。この例では、いくつかのアプローチを説明したいので、Vue CLIのようなすぐに使えるソリューションは適用しない。

魔法のようなリントスクリプトの下にあるものを理解する時が来た！

2.典型的なNodeプロジェクトの拡張

高品質なソリューションを提供するために、新しいプロジェクトを立ち上げる際にまず始めなければならないのがリンターです。ここでは2つのリンターに注目してみましょう - スタイル用のStylelint (*.scss)とソースファイル用のESLint(*.js).これらのリンターはどちらもNPMで利用可能で、設定もとても簡単です。リンターを使うには、インストール手順を踏み、設定ファイルを追加し、プロジェクトスクリプトを定義する必要がある。順を追って説明しよう。

3.Stylelintの追加

Node環境へのStylelintのインストールはとても簡単です。以下の公式ドキュメントただ走るだけでいい：

npm install --save-dev stylelint stylelint-config-standard

そして完成するまで待つ。

stylelint-config-standard はデフォルトのリンティングルールセットを提供し、あなたのニーズに合った任意のパッケージに置き換えることができます（例えば Airbnbスタイル).次に新しい隠しファイルを作成する。 .stylelintrc.jsonこれはStylelintの設定ファイルであり、事前に定義されたルールを読み込む役割を担っています：

{
    "extends"："stylelint-config-standard"
}

今現在、唯一欠けているものは、SCSSファイルのリンティングを開始するためにpackage.jsonファイルで宣言されたNPMスクリプト(またはスクリプト)です。これが私の提案です：

"スクリプト"：{
    "lint:scss"："stylelint '**/*.scss' --syntax scss -f verbose --color"、
    "lint:scss:fix"："stylelint '**/*.scss' --syntax scss --fix -f verbose -color": "stylelint '**/*.scss' --syntax scss -f verbose --color".
}

ご覧のように、私はこのスクリプトに -修正 オプション - これは変更をリポジトリにプッシュする前に使用します。

覚えておいてほしい。 -修正 というのも、本番環境に渡すコードがリポジトリで正しくスタイルされないからです。 だから、両方の脚本が必要なんだ。

リンターをテストしてみよう。 /assets/scss/styles.scss というような内容だ：

ボディ
                    background-color:#fff；
}

npm run lint:scss

コンソールには次のように表示されるはずだ：

> stylelint '**/*.scss' --syntax scss -f verbose --color

assets/scss/styles.scss

2:21 ✖ 期待されるインデント2スペースインデント

1ソースをチェック

~/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

1 つの問題が見つかりました

深刻度レベル「エラー1

インデント1

npm ERR！コード ELIFECYCLE

npm ERR!

npm ERR! [email protected] lint:scss：`stylelint '**/*.scss' --syntax scss -f verbose --color`.

npm ERR！終了ステータス 2

これは実際に、我々のリンターが機能していることを意味する！

出力は、どの行でエラーが発生したかを正確に示し、解決すべき問題を説明する。開発者の判断が必要なため、自動的に修正できない問題もあるが、大半の場合は、同じコマンドを -修正 オプションがあるので、実行してみよう。

npm run lint:scss:fix

これでエラーが見つからず、緑色の出力が表示されるはずだ：

stylelint '**/*.scss' --syntax scss --fix -f verbose --color


1ソースをチェック

/Users/wojciechbak/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

0 個の問題が見つかりました

4.ESLintの追加

このステップは前のステップとほとんど同じです。ESLintをインストールし、デフォルトのルールセットを定義し、2つの呼び出し可能なNPMスクリプトを宣言します。それでは見ていきましょう！

日常業務でNPMを使用している場合、ESLintをグローバルにインストールしたいと思うかもしれません。そうでない場合は公式ドキュメント.

npm install -g eslint

あなたのマシンでeslintコマンドが使えるようになったら、プロジェクトでこれを実行すればいい：

eslint --init

ターミナルに表示される指示に従い、以下のようにいくつかのプロジェクトを決定するだけだ：

ジャバスクリプトまたはTypeScript
AirbnbスタイルかGoogleスタイルか
設定タイプ（JSONファイル、JSファイル、またはインラインの package.json)
ESモジュール(輸出入または必要構文

ここで、Prettierと呼ばれるコードフォーマッターについて一言書いておこう。これは完全に標準化されており、ほとんどのコードエディター（VS Codeなど）と互換性がある。Prettierは、あらかじめ定義されたコード・スタイリング・ルールのセットを多数提供し、リンターと連携して、コードの最高品質を追求する上で大きなサポートとなる。Prettierとは何かを理解するには、こちらをご覧ください。比較公式資料より

もしそうなっていれば、ESlintの設定ファイル（例えば .eslintrc.jsonの隣に表示されるはずだ。 .stylelintrc.json 以前から作られていた。

スクリプトを package.json ファイルの場合と同じです：

"スクリプト"：{
    "lint:js"："eslint '**/*.js' --ignore-pattern node_modules/"、
    "lint:js:fix"："eslint '**/*.js' --ignore-pattern node_modules/ --fix" "
}

おめでとう！ESLintはすぐに使えます。正しく動作するか確認してみましょう。作成する /src/index.js ファイルにいくつかのコンテンツを追加する：

console.log("something")；

リンターを走らせる：

npm run lint:js

出力は次のようになるはずだ：

> eslint '**/*.js' --ignore-pattern node_modules/

~/コード/プロジェクト/github-workflow-demo/src/index.js

1:1 警告予期しないコンソールステートメント no-console

問題 ✖ 1件（エラー0件、警告1件）

を使ってもこの警告は消えない。 -修正 というのも リンターは潜在的に意味のあるコードには影響しない。リンターはコードのスタイリングのためだけにある。空白、改行、セミコロン、引用符などを含む。

5.GitHubワークフローの定義

GitHubワークフローはかなり文書化されているものだ。しかし今は、リモート・リポジトリ（当然、GitHubにホストされている）へのプッシュ後にコードをlintする簡単なワークフローを実装することにしよう。

作成 /.github/ワークフロー ディレクトリと新しい コードクオリティ・ワークフロー.yml GitHub のワークフローは YAML ファイルで定義する必要があります。

適切なワークフローを実行するには、いくつかの質問に答えなければならない：

ワークフローをいつ実行するか（プッシュ時、プルリクエスト時、マージ時など）。
ある状況（ブランチマスターへのプッシュなど）を除外したいのか？
コマンド（この例ではNode）を正しく実行するためには、どのような環境をセットアップする必要があるのでしょうか？
依存関係をインストールする必要があるのか？もし必要なら、どのようにキャッシュすればいいのでしょうか？
チェックを完了させるためには、どのような手順が必要か？

いくつかの検討と、ドキュメントの例での数時間の作業の後 .yml ファイルは次のようになる：

name: コード品質

on: 'push'

ジョブを実行します：
  code-quality：
    name: Lint ソースコード
    実行: ubuntu-latest
    ステップ
    - uses: actions/checkout@v1

    - name: ノードのセットアップ
      uses: アクション/セットアップノード@v1
      を使います：
        ノードバージョン: '12.1'

    - name: キャッシュの依存関係
      uses: アクション/キャッシュ@v1
      と一緒に
        パス: ./node_modules
        key: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        復元キー：|
          $(( runner.OS ))-dependencies-$(( env.cache-name ))-)
          $(((ランナー.OS ))-依存関係-)
          $(((ランナー.OS ))-)

    - name: 依存関係のインストール
      を実行します：|
        npm インストール

    - name: リントファイル
      を実行します：|
        npm run lint

GitHubは私たちが必要とするすべての環境的なものを提供してくれる。最後の行では、コマンド npm run lint これは以前には定義されていなかった：

"スクリプト"：{
    "lint"："npm run lint:js && npm run lint:scss"
}

なお、今回のワークフローでは修正コマンドを使用する。

これらの手順がすべて完了したら、Pull Request をマージする前に GitHub からこの美しい出力を楽しむことができます：

エンタープライズ＆スケールアップ・ソリューション

強力で結束力のあるチーム作りのベストプラクティス

ソフトウェア開発を成功させるためには、コラボレーションが不可欠です。協力し合える強力なチームは、より良い成果を達成し、課題を克服することができる。コラボレーションを促進するには、努力、コミュニケーション、継続的な...

クリスティアン・バルチャンスキーフロントエンドユニットリーダー

ソフトウェア開発

Agile Methodologyの実装方法

アジャイル開発手法をマスターし、ソフトウェア開発におけるプロジェクト管理を強化し、実装を成功させるためのベストプラクティスを学ぶ。

ザ・コデスト