ESLint + StyleLint + Prettier + VSCode により、最もエレガントなフロントエンド開発エクスペリエンスを作成

ESLint + StyleLint + Prettier + VSCode により、最もエレガントなフロントエンド開発エクスペリエンスを作成


序章

成熟したフロントエンド チームにとって、統一されたコーディング標準と提出標準は特に重要です。順序、統一されたスタイル、順序を確保するには、単に仕様を文書に記述するだけではあまり実用的ではありませんコードを記述するときに、ルールを 1 つずつ読んで暗記し、最終的にそのルールに従うことを希望する人はいません。

適切に開発し、コードの堀の品質を維持する方法は、検討に値する問題です。

この記事は上記記事のサイドストーリーであり、元の記事の内容に加えて、スタイルをチェックするための StyleLint 、コードの美化と ESLint と StyleLint とのエレガントな連携のための Preiiter の追加、および VSCode の設定を追加しています。 VSCode での一連の開発エクスペリエンスをそのまま実現します

概要

理想的な開発エクスペリエンスは次のように抽象化できます。

エレガントなワークフローにより、ビジネス コードのみを気にするだけで済み、デバッグ時にすべてのコードがソース コード内に含まれ、製品は仕様要件を満たします。

ただし、仕様の要件を真に満たすためには、文字どおりの制約開発認識だけに依存するだけでは十分ではなく、開発が自動ツールを使用して仕様の要件を完了できるようにエンジニアリング手法を使用する必要があります。開発プロセスと開発自体は事業開発への投資に専念できます

**この記事では、eslint、stylelint、prettier、vscode、standardjs、husky、lint-staged、commitizen、commitlint およびその他のツールを組み合わせて、フロントエンド仕様ソリューションを体系的に構築します。
**

次に検討するのは、仕様全体をツール (堀) として記述し、ワンクリックで他のプロジェクトに適用できるようにすることです。

コーディングの制約

フロントエンドのコーディング仕様は主にJSとCSSの2つで構成されており、ランディングプロジェクトではそれぞれESLintとStylelintを使用し、コーディングスタイルを統一するためにPrettierを組み合わせています。以下に示すように:

ESLint + StyleLint + Prettier でコーディング制約の自動化を完了

ESLint

このプロジェクトは ESLint を統合して、JavaScript の問題を自動的に検出して修正します。ここで、 .eslintrc.js は eslint の構成ファイルです。プロジェクトによって構成は異なりますが、このプロジェクトで使用する構成内容は次のとおりです。

module.exports = {
  env: {
    browser: true,
    es2021: true,
  },
  extends: ['plugin:react/recommended', 'standard', 'plugin:prettier/recommended'],
  parser: '@typescript-eslint/parser',
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 'latest',
    sourceType: 'module',
  },
  plugins: ['react', '@typescript-eslint'],
  rules: {
    // eslint 规则写这里
    'comma-dangle': ['error', 'only-multiline'],
  }
}

設定の具体的な意味と機能については、[ESLint]( https://github.com/eslint/eslint ) 公式 Web サイトのドキュメントを参照してください。

インストールする必要があるパッケージは次のとおりです。

eslint : ESLint プログラム エントリ。JS ファイルのプログラムを実行するために lint-staged で設定されます。
eslint-config-standard : 一般的な ESLint ルール設定のセット。
eslint-config-prettier : Prettierと競合する可能性のあるESLintルールをオフにし、ESLint + Prettier時の競合を解決します
eslint-plugin-prettier : Prettierのプラグインで、ESLint + Prettierを組み合わせて使用​​できるようにします。Prettier のフォーマット操作を ESLint のプロセスで実行すると、Prettier によって検出されたフォーマットの問題は ESLint のプロセスで自動的に修復されます。

このうち、eslint-config-standard は、 JavaScript Standard Style によって提供される、業界で一般的な ESLint ルール設定のセットです。具体的な個別ルールについては、https: //standardjs.com/rules.htmlを参照してください。

JavaScriptの標準スタイル

上記の ESLint 構成ファイルの extends フィールドで構成された標準は、検証と修復のルールがJavaScript 標準スタイル標準を使用することを示しています

standardjs は、スタイルとプログラムの問題を事前に検出し、コード レビュー プロセスで繰り返される修正プロセスを減らし、時間を大幅に節約し、グローバルな統一性を維持できます。

デフォルトでは、standardjs を使用するだけで十分です。追加のルールを作成する必要はありません。実際の開発で必要な場合は、 .eslintrc.jsルールで設定できます。

スタイルリント

Stylelint は、開発者が CSS コード内のエラーを回避し、一貫したコーディング スタイルを維持できるようにする強力で高度な CSS コード チェッカー (リンター) です。

次の機能があります。

最新の (最新の) CSS 構文と機能を理解している エラーをキャッチし、コーディング規約を強制するための170
を超える組み込みルールがある独自のルールを作成するプラグイン
をサポートしているコードの書式設定に関するほとんどの問題を自動的に修正する成長するコミュニティがあり、Google、GitHub、およびワードプレス

次のように拡張することもできます。

SCSS、Sass、Less、SugarSS などのCSS のような構文を解析し、HTML、Markdown、CSS-in-JS オブジェクトおよびテンプレート テキストから埋め込みスタイル コード
を抽出します。

インストールする必要があるパッケージは次のとおりです。
stylelint : Stylelint のプログラム エントリ。スタイル ファイルのプログラムを実行するために lint-staged で設定されます。
stylelint-config-standard : Stylelint によって合意されたルール設定セット。Stylelint は
stylelint-config-prettierを実行します。このルールに従って: Prettier と競合する可能性のあるルールを閉じ、Stylelint + Prettier 時の競合問題を解決します。
stylelint-prettier : Prettier のプラグインで、Stylelint + Prettier が使用できるようになります。Prettier のフォーマット操作を Stylelint プロセスに属するようにすると、Prettier によって検出されたフォーマットの問題も Stylelint プロセス中に自動的に修復されます。

このうち、stylelint-config-standard は、業界全体の Stylelint ルール設定のセットです。The Idiomatic CSS PrinciplesGoogle の CSS スタイル ガイドAirbnb のスタイルガイド@mdo のコード ガイド などの特定のルールを含めます

より美しく

Prettierは、多数のプログラミング言語をサポートする「態度」コード書式設定ツールです。ESLint (主に文法エラーに焦点を当て、一部の書式設定を行う) と比較して、コードのスタイルとスタイルに重点を置いています。したがって、エレガントで完璧な開発を行うには、日常の開発で Prettier と ESLint を併用する必要があります。

このプロジェクトの構成については、prettier.config.js ファイルを参照してください。

インストールする必要があるパッケージは次のとおりです。

より美しい

コミット制約

ESLint + Stylelint + Prettier の設定は以上で完了しました。プロジェクト内で、yarn eslint xx.tsx 、yarn stylelint xx.less 、yarn prettier xx.mdなどを使用して、さまざまなファイルを検証および修復できます。ただし、コマンドを手動で実行するために開発に依存するのは現実的ではなく、開発を自動的に完了するためのエンジニアリング手法が依然として必要です

以下では、husky + lint-staged + commitizen + commitlint を使用して、サブミット時に検証と修復を自動的に実行し、同時にサブミット自体の形式を制約する方法について説明します。コアプロセスを以下の図に示します。

制約コアプロセス図を送信する

コミット者

Commitizenは、git コミット メッセージをフォーマットするためのツールで、必要なコミット情報を取得するためのクエリ スタイルの方法を提供します。

お問い合わせの送信

cz-conventional-changelog は、送信の種類が問題修正なのか機能開発なのか、送信の範囲など、送信時に入力する必要がある情報を指定するために使用されます。 cz-conventional-changelog は、によって提供されるルールです。プロジェクトの実際の状況に応じて適切なルールを自分で作成することもできますが、この段階では十分であり、変更する必要はありません。

Windows プラットフォームは送信する git commit の多重化をサポートしていないため、package.json のcz script コマンドを通じて送信できます。

 // package.json
 "scripts": {
    
    
    "cz": "git-cz"
 } 

基本的に、送信するプロジェクトのルート ディレクトリでgit-czコマンドを実行するため、 yarn cz**、yarn git-cznpm run cz、**npx git-czのいずれかを使用して送信を完了できます。

インストールする必要があるパッケージは次のとおりです:
commitizen
cz-conventional-changelog

ハスキー + 糸くずステージ

husky は git フックを処理するツールで、git フックをインターセプトして「送信形式の検証」や「コードの検証」などが可能になります。

lint-staged は、ステージング領域での lint 操作のためのツールです。第一に、グローバル コードを毎回 lint する必要がないため、時間が節約されます。第 2 に、古いプロジェクトに lint ルールを適用する場合、歴史的な理由によりすべての送信が通過できないため、これから適用されるコードのみを lint する必要もあります。提出されました。

ツールの使用方法については、「ハスキー」を参照してください。

現在変更されている部分のみを検出するには、lint ステージングツールを組み合わせて使用​​します。

// package.json
 "lint-staged": {
    
    
  "*.{js,jsx,ts,tsx}": [
     "eslint --fix"
  ],
  "*.{less,css}": [
     "stylelint --fix"
  ]
 }

husky をインストールすると、git フックの構成用にプロジェクトのルート ディレクトリに追加の .husky フォルダーが作成されます。同時に、js、jsx を送信するときに、上に示すように、package.json に lint ステージングされた構成を追加します。 、ts、tsx の場合は検証と自動修復に eslint を自動的に使用し、less と css の場合は送信時に検証と修復に styleint を自動的に使用します。

合格したコードのみを提出し、仕様を満たしていない部分がある場合は提出時にエラーを報告し、必要に応じて修正することができます。

インストールする必要があるパッケージは次のとおりです。

husky : git フックを処理します
lint-staged : ステージング領域でのみ有効です

husky+lint-staged を使用すると、サブミット時にインターセプトして自動的に修復されます。開発中にリアルタイムでエラーを通知でき、保存時にエラーを自動的に修復できれば、サブミット時に集中的にエラーを修復する問題を回避できます。実装方法については、プロジェクト構成の章を参照してください。

コミットリント

クエリ形式の送信方法は上記の commitizen によって実装されていますが、開発がこの規約に従うことを保証する方法はありません。開発エラーを防ぐために、git commit を使用して自分でコードを送信するため、commitlint を使用して検証してください。ウェアハウスに提出する前に、提出情報を確認してください。

commitlint はコミットが仕様に準拠しているかどうかをチェックするツールです。

必要なインストール パッケージは次のとおりです。

@commitlint/cli : 検証用の実行エントリである Commitlint は husky と併用し、commmit-msg の git フックを使用してコード送信時にコミット情報を確認し、送信仕様を満たしていない場合はエラーメッセージが表示されます。報告されます。
@commitlint/config-conventional Angular チームによって作成された、共通の送信情報検証スキームのセット。必要に応じて、独自のチームの仕様をカスタマイズすることもできます。

エンジニアリング構成

標準ツールと検証ツールは以前にデプロイされ、送信も傍受されたため、コードの品質はすでに保証されています。しかし、開発の効率をさらに向上させるためには、送信時に大量の検証エラーが見つかることは望ましくありません。

以下では、vscode を例として、開発プロセス中にリアルタイムでエラーを表示しワンクリックで自動的にフォーマットおよび修復する機能を実現し、すべての開発で一貫したすぐに使用できるようにします。

他のエディタも同様です。それぞれのエディタの設定を参照してください。

VSCodeプラグイン

開発中にエディターで自動的にエラーを表示し、自動的に修正するようにしたい場合は、必ず ESLint プラグインと StyleLint プラグインをインストールしてください。

プロジェクトが依存するプラグインは .vscode/extensions.json で構成されます。将来的に新しい依存プラグインがある場合は、ここで構成して送信することで、すべての開発者がプラグインの統合に依存できるようになります。インチ。

{
    
    
 "recommendations": ["dbaeumer.vscode-eslint", "stylelint.vscode-stylelint"]
}

現在必要なのは ESLint と StyleLint のみです。

プラグインのインストール後、コードにエラーがあると、次の図に示すようなエラー メッセージが表示されます。

Modern.js から引用、侵入され削除されました

同時に、ファイル名と右側のプレビューボックスにヒントがあり、非常に目を引きます。

VSCodeの設定

プロジェクトが依存する vscode 設定は .vscode/setting.json にあり、これらの設定により「リアルタイムでエラーを編集」、「保存時に自動的に修復」、「適切なときに自動的に修復」が可能になります。クリックしてファイルをフォーマットします。」

プラグインをインストールした後、さまざまな開発ニーズに合わせてプラグインを構成する必要があります。

たとえば、typescript、javascript、typescriptreact、javascriptreact およびその他のファイルのデフォルトの書式設定ツールを eslint の自動修復に設定する必要があります。このように、これらのファイルで右クリックしてドキュメントを書式設定すると、検証と書式設定のために eslint が自動的に呼び出されます。

StyleLint も同様に設定されます。

この記事のプロジェクトの構成は以下の通りで、保存時の自動lintがオンになっており、ファイル保存時にすべてのチェックと修復が自動的に完了します。

{
    
    
  "eslint.run": "onType",
    "eslint.codeActionsOnSave.mode": "all",
      "eslint.format.enable": true, // 允许eslint 格式化对应的文件
        "[typescript]": {
    
    
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
      "editor.codeActionsOnSave": {
    
    
      // 开启保存时执行eslint进行校验和格式化
      "source.fixAll.eslint": true
    },
    "editor.formatOnSave": false // 所以编辑器默认的格式化设置为false,避免重复格式化
  },
  "[javascript]": {
    
    
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
      "editor.codeActionsOnSave": {
    
    
      "source.fixAll.eslint": true
    },
    "editor.formatOnSave": false
  },
  "[typescriptreact]": {
    
    
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
      "editor.codeActionsOnSave": {
    
    
      "source.fixAll.eslint": true
    },
    "editor.formatOnSave": false
  },
  "[javascriptreact]": {
    
    
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
      "editor.codeActionsOnSave": {
    
    
      "source.fixAll.eslint": true
    },
    "editor.formatOnSave": false
  },
  "[sass]": {
    
    
    "editor.defaultFormatter": "stylelint.vscode-stylelint", // 设置编辑器默认格式化工具为stylelint
      "editor.codeActionsOnSave": {
    
    
      "source.fixAll.stylelint": true // 保存时自动使用sytlelint 修复
    },
    "editor.formatOnSave": false // 关闭编辑器默认的保存格式化
  },
  "[css]": {
    
    
    "editor.defaultFormatter": "stylelint.vscode-stylelint",
      "editor.codeActionsOnSave": {
    
    
      "source.fixAll.stylelint": true
    },
    "editor.formatOnSave": false
  },
  "[less]": {
    
    
    "editor.defaultFormatter": "stylelint.vscode-stylelint",
      "editor.codeActionsOnSave": {
    
    
      "source.fixAll.stylelint": true
    },
    "editor.formatOnSave": false
  }
}

要約する

最後に、すべてのフロントエンド倉庫が都市の防衛に成功することを願っています。

おすすめ

転載: blog.csdn.net/zqd_java/article/details/128398198