単純さについての困難：チームのESLint

小さな紹介。 ほとんどの場合、この投稿はESLintとは何かを知っている人にだけ興味深いものですが、それでも私は小さな紹介をします。さもなければ、出版物を開くと非常に怒って、「あなたが話しているxxxを10年間使っています」という言葉で始まりますご存知ですが、xxx.yyyについて書くことにしました。これは誰もやったことがありませんが、おそらくとてもクールです。」



そのため、 ESLintは、選択したJavaScript標準で記述されたコードの品質を分析できるクールなツールです。 コードをほぼ均一なスタイルにし、愚かな間違いを回避し、見つかった問題の多くを自動的に修正し、多くの開発ツール（hello、Jetbrains、私たちはあなたを愛しています！）と完全に統合できます。 ちなみに、彼は、他のリンターのように、あなたに特定のスタイルを義務付けません。 それどころか-ベストプラクティスから何かを選択し、必要に応じて変更できます。









アプリケーションの中では、まったく予期しないケースを見つけることができます。たとえば、リンターを自動的に修正することでレガシーコードを実行しやすくなり、エラーをそのまま修正するよりもよく見える最新の標準になります。 その結果、無効な構成体が判明する可能性がありますが、私たちの観察によると、これは変換前にうんざりするコードがあったことを意味します。



一般に、2017年にNode.JSでリンターなしで生活することは、片手に座ってメモ帳でコードを書くようなものです。



そして今日、私は彼が個人としてではなく、チームとして効果的に働くためにどのようにそれを実装することに決めたかをお話しします。



大企業はCIプロセスの一部としてリンターテストを行っていますが、すぐにそれを説明します。 しかし今のところ、私たちは主な必要性を認識する必要があります-開発者からのリンターの立ち上げ、すべてがうまくいき、ほぼ同じように動作することを保証します。



どうやら-それは何ですか、プロジェクトに.eslintrc.jsonを追加して、始めましょう！ しかし、疑問が生じます。ESLintをどのように、どこで、誰によって配置する必要があり、コードスタイルに必要なプラグインの束ですか？ 通常、これには3つのアプローチが使用されます。

1. それらをdevDependencyに入れましょう。
2. それらをどこにも置かないようにしましょう。 誰もがモカ\エスリント\スタッフを世界中に持ちましょう。
3. gulpやgruntなどのタスクマネージャーによるチェックですべてを設定して実行します。

2番目のオプションはすぐに排除されます。この方法では、プロジェクトごとにツール自体のバージョン管理が失われ、ツールとプラグインをグローバルにインストールするだけではまったくクールではないことは明らかです。



3番目のオプションは悪くありませんが、これまでのところ、なんとかしてタスクマネージャーなしで管理しています。 そのようなタスクのプロジェクトにそれらを追加すると、明らかに過剰になります。



通常、最初のオプションはgithubプロジェクトに最適ですが、商業開発にはあまり適していません。 私たちのCIは、テストサーバーで自動テストを実行するために用意されており、devDependencies以外にテストの依存関係を登録する場所はありません。 しかし、問題はこれではありませんが、自動テストとは異なり、リンター用のツールはテストサーバーに行くべきではありません。 少なくともプロジェクトが展開されると、30の代わりに200メガバイトを超える重量が突然発生し始めます。これは重要ではないと考える人もいますが、PCI DSS標準に準拠するために、あらゆる場所でかなり深刻な暗号化を使用しているため、 200メガバイトには貴重な時間がかかります。 したがって、最初のオプションも私たちには適していません。 要約すると：

• リンターとそのプラグインはグローバルに立つべきではありません。
• 特定のプロジェクトは、ツールの特定のバージョンにリンクする必要があります。
• これらのツールは、依存関係やdevDependenciesに置かないでください。

一見すると、簡単な解決策が提案されます。たとえば、npmスクリプトを実行し、たとえばnpm run lint-installを実行すると、指定したバージョンのすべてのパッケージをコマンドラインから入力するbashスクリプトがプルされます。 しかし、このようなソリューションの不器用さに加えて、依存関係の一部（開発上のものではあるが）がpackage.jsonを別のbashスクリプトに残すことも判明しています...そして、これはまったくクールではありません。 さらに考えて、package.jsonの仕様を思い出してください。 一般的に、誰もあなたがそこに好きなセクションを追加することを気にしません-しかし、私は特定の基準に従いたいです。



package.json仕様から、 peerDependenciesのようなかなり奇妙でめったに使用されないセクションがあることを思い出してください ：

場合によっては、ホストツールやライブラリとパッケージの互換性を表現したいが、必ずしもこのホストの要件を実行する必要はありません。 これは通常、プラグインと呼ばれます。 特に、あなたのモジュールは、ホストのドキュメントによって期待され、指定された特定のインターフェースを公開している可能性があります。

自動的に設定されませんが、小さな落とし穴はあります：

注：npmバージョン1および2は、依存関係ツリーの上位に明示的に依存していない場合、peerDependenciesを自動的にインストールします。 npmの次のメジャーバージョン（npm @ 3）では、これは当てはまりません。 代わりに、peerDependencyがインストールされていないという警告が表示されます。 npms 1と2の動作はしばしば混乱を招き、あなたを依存関係の地獄に簡単に陥らせる可能性があります。npmsは可能な限り回避するように設計されています。

幸い、npmは2番目ではなかったので、突然の結果を恐れることなくこのセクションを安全に使用できました。 しかし、問題は彼らが待たなかったところから来ました... peerDependenciesの無人インストールをアンインストールするとき、npmの作者はそれらを手動で置く方法を作らないことが判明しました。 したがって、peerDependenciesセクションで利用できるのは、それらがインストールされていないという警告だけです。 これらの依存関係はオプションですが、これは部分的に説明可能です。 このような変更の後、すべての開発者が単純にすべてをdevDependenciesに移行したのではないかと疑っています...そして、依存関係の地獄はなくなりませんでした。

ちなみに、そのようなオプションの欠如は私には奇妙ではないようでした。 これについても問題があります-閉じられていますが、パッチ歓迎としてマークされています。 つまり、npmの作成者は一般にこれがわき柱であることに同意します-修正するのに十分な時間がありません...



そのため、セクションがありますが、どのように使用するかは明確ではありません。 同じ問題の18のいいねには、そのような解決策があります。

npm info . peerDependencies | sed -n 's/^{\{0,1\}[[:space:]]*'\''\{0,1\}\([^:'\'']*\)'\''\{0,1\}:[[:space:]]'\''\([^'\'']*\).*$/\1@\2/p' | xargs npm i
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

地獄だと思う。 チームリーダーとして、私はこれが私たちのプロジェクトに入ることを許せません...



一般に、このアイデアは、package.jsonを解析してnpm installを呼び出すことができるツールを作成または検索することを目指していますが、上記のスクリプトほど難しくはありません。 多かれ少なかれnpm-install-peersは私を満足させた。 彼には2つのマイナス点があります。

1. なんらかの理由でシステムにnpmがインストールされていない場合（実際にインストールされる）、彼は...ローカルに再インストールするため、時間、トラフィック、そしてあらゆる種類の地獄のようなエラーが発生します。
2. 彼は引数をサポートしていません。 ウィンドウ上のシンボリックリンクがすでに有効になっていて、-no-bin-linksがあまり関係ない場合は、-productionがまだ望ましいです。 同じリンターの依存関係の場合、これによりインストール時間が大幅に節約されます。

おそらく近い将来、同じことをするが、モジュールとしてではなくbashを介してnpmをプルする同様のインストーラーを実行するでしょう。 それはそれほど美しくないかもしれませんが、引数ですべてが明確であり、2回目はnpmをインストールする必要はありません。 そして、引数を渡したい-少なくともeslintとそのプラグインからdevDependenciesをインストールしない。



次に質問が発生します-実際にnpm-install-peersをグローバルにインストールする方法は？ デフォルトで考慮しますか？ スクリプトを実行するときに静かに設定しますか？ devDependenciesでローカルに設定しますか？ 私はどのオプションも好きではありませんでした。 その結果、次のような簡単な解決策に満足しました。

 "lint-install": "npm-install-peers || echo 'Please run npm install -g npm-install-peers first'",
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このオプションは、開発者にとって最も透過的であるように思えました。



あとは、実際に必要なリンターとpeerDependenciesを開始するスクリプトを追加するだけです。 スクリプト：

 "lint": "./node_modules/eslint/bin/eslint.js app.js routes modules test App.js"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存関係：

 "peerDependencies": { "babel-cli": "^6.23.0", "babel-preset-es2015": "^6.22.0", "eslint": "^3.16.0", "eslint-config-airbnb": "^14.1.0", "eslint-plugin-import": "^2.2.0", "eslint-plugin-jsx-a11y": "^4.0.0", "eslint-plugin-promise": "^3.4.2", "eslint-plugin-react": "^6.10.0", "eslint-plugin-standard": "^2.0.1" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、副次的な機能として、peerDependenciesに、テストに関係しない他のあらゆる種類の依存関係（たとえば、神聖なjsdoc-to-markdown）を配置できるようになりました 。



単純なタスクのように思えますが、あらゆる種類の興味深いニュアンスが非常に多いことが判明しました。 そして、私はそれがより簡単に、より良くできると完全に認めています。 企業プロジェクトにリンターをどのように使用しますか？