はじめに

NPM

NPM は JavaScript 開発のデフォルトのパッケージマネージャです。
自分のプログラムで使えるパッケージ（プログラム）を探してインストールするのに役立ちます。

npm init コマンドを使うだけで、プロジェクトに npm を追加することができます。
このコマンドを実行すると、カレントディレクトリに "package.json" ファイルが作成されます。
このファイルには依存関係がリストアップされており、npm はこのファイルをプロジェクトの ID カードとみなします。

依存関係を追加するには、"npm install (package_name)" コマンドを実行します。

このコマンドを実行すると、npm はリモートレジストリに移動し、このパッケージ名で識別されるパッケージがあるかどうかをチェックします。
見つかった場合、新しい依存関係が package.json に追加され、内部依存関係を含むパッケージがレジストリからダウンロードされます。

ダウンロードされたパッケージや依存関係は "node_modules" フォルダの下にあります。
ただ、通常はかなり大きくなることに注意してください
node_modulesは**.gitignore に追加するようにしてください。**

NPM は、パッケージを探したりダウンロードしたりする作業を簡単にするだけでなく、プロジェクトでの共同作業をより簡単にしてくれます。

NPM がなければ、外部の依存関係を管理するのは難しいでしょう。
既存のプロジェクトに参加するときには、すべての依存関係の正しいバージョンを手でダウンロードしなければなりません。これは本当に面倒なことです。

npm の助けを借りれば、"npm install" を実行するだけで、すべての外部依存関係をインストールしてくれます。
そうすれば、あなたのチームの誰かが新しい依存関係を追加したときに、いつでもそれを実行することができます。

Babel

Babelは、ECMAScript 2015+のコードを古いJavaScriptエンジンでも理解できるコードに翻訳するJavaScriptコンパイラまたはトランスパイラです。

Babel は最もポピュラーな JavaScript コンパイラであり、Vue や React などのフレームワークはデフォルトで使用しています。
とはいえ、ここで話すコンセプトは Babel に関連するものだけではなく、どの JavaScript コンパイラにも適用されます。

"なぜコンパイラが必要なのか？JavaScriptは解釈言語ではないのか？"と、コンパイルされた言語と解釈言語の概念に精通している人は疑問に思うかもしれません。

確かに、人間が読めるコードをCPUが理解できる実行可能なバイナリに変換してくれるものを「コンパイラ」と呼ぶことが多いです。しかし、ここではそうではありません。

トランスパイラーはコンパイラのサブセットなので、トランスパイラーという言葉の方が適切かもしれません。
トランスパイラとは、プログラミング言語のコードを別の言語に翻訳するコンパイラのことです (この例では、最新の JS から古いバージョンの JS に翻訳します)。

JavaScriptはブラウザの言語です。しかし、ブラウザには問題があります。クロス・コンパティビリティです。
JavaScript のツールや言語自体が急速に進化しており、多くのブラウザはそのペースに追いつけていません。その結果、互換性の問題が発生します。

おそらく、JavaScriptの新機能を利用できるように、JavaScriptの最新バージョンでコードを書きたいと思うでしょう。
しかし、あなたのコードを実行しているブラウザが JavaScript エンジンの新機能の一部を実装していない場合、そのブラウザではコードは正しく実行されません。

これは複雑な問題です。そして、たとえそれらの新機能を実装したとしても、古いバージョンのブラウザを使用している人が常に存在することになります。

では、最新の機能を使用しながらも、ユーザーに問題なくページを閲覧してもらいたい場合はどうすればいいのでしょうか？

Babel が出る前は、ブラウザが最新の機能をサポートしていない場合に、古いバージョンのコードを実行するためにポリフィルを使用していました。
しかし、Babel を使用すると裏で polyfills を使用しているので、何もする必要がありません！

Webpack

Webpackは静的なモジュールバンドルです。あなたが新しいプロジェクトを作成するとき、ほとんどのJavaScriptフレームワーク/ライブラリは、これを使用しています。

static module bundler というフレーズが紛らわしく聞こえる場合は、理解を助けるためにいくつかの素晴らしい例があるので読み続けてください。

なぜバンドラーが必要なのか？
ウェブアプリでは、たくさんのファイルを持つことになります。これは特にシングルページアプリケーション（React, Vue, Angular）の場合に顕著で、それぞれに依存関係があります。

依存関係とは、インポート文のことで、ファイルAが正しく動作するためにファイルBをインポートする必要がある場合、AはBに依存していると言えます。

小さなプロジェクトでは、モジュールの依存関係を [ script ] タグで扱うことができます。
しかし、プロジェクトが大きくなると依存関係の管理は急速に難しくなります。

おそらく、もっと重要なのはコードを複数のファイルに分割することで、ウェブサイトの読み込みが遅くなることです。
これは、ブラウザが1つの大きなファイルに比べてより多くのリクエストを送信する必要があるためで、HTTPヘッダのためにWebサイトが大量の帯域幅を消費し始めるからです。

開発者としては、コードはモジュール化したいものです。我々は何千もの行を持つ1つのファイルで動作するようにしたくないので、我々は複数のファイルに分割します。
しかし、私たちのウェブサイトはパフォーマンスが高く、帯域幅の使用量が少なく、高速に読み込まれるようにしたいと考えています。

そこで、Webpackがこの問題をどのように解決するかを見てみましょう。

Webpackの仕組み

Babelの話をしているときに、デプロイ前にJavaScriptのコードをトランスパイルする必要があることを述べました。

しかし、プロジェクトをデプロイする前に必要な操作は、Babelでコンパイルすることだけではありません。

通常はトランスパイルして、SASS や SCSS を CSS にコンパイルして、プリプロセッサを使用している場合は TypeScript をコンパイルして...と、このリストはすぐに長くなります。

毎回のデプロイの前に、これらのコマンドや操作をすべて扱いたくはないでしょう。これらのコマンドや操作を正しい順序で、正しい方法で行うツールがあれば最高です。

それがWebpackです。

Webpackは、開発体験をより良いものにするために、ホットリロードによるローカルサーバーのような機能も提供しています。

では、ホットリロードとは何でしょうか？それは、あなたがコードを保存するたびに、コンパイルされ、あなたのマシン上で実行されているローカルの HTTP サーバーにデプロイされることを意味します。
また、ファイルが変更されるたびにブラウザにメッセージが送信されるので、ページを更新する必要がありません。

「npm run serve」や「npm start」、「npm run dev」を使ったことがある人は、これらのコマンドもWebpackの開発サーバーを裏で起動します。

Webpack はプロジェクトのエントリポイント (インデックス) から起動し、ファイルの抽象構文ツリーを生成します。これはコードを解析していると考えることができます。この操作はコンパイラでも行われ、インポート文を再帰的に探して依存関係のグラフを生成します。

そして、ファイルをIIFEに変換してモジュール化します(コードを関数の中に入れるとスコープが制限されることを覚えておいてください)。これを行うことで、ファイルをモジュール化し、変数や関数が他のファイルにアクセスできないようにします。

この操作がなければ、インポートしたファイルのコードをコピー＆ペーストするようなもので、そのファイルは同じスコープを持つことになります。

Webpackは裏で他にも多くの高度なことをしていますが、基本を理解するにはこれだけで十分です。

ESLint

コードの品質は重要であり、プロジェクトの保守性と拡張性を維持するのに役立ちます。私たち開発者の多くは、クリーンなコーディングの重要性を認識していますが、納期のプレッシャーの中で長期的な結果を無視してしまうことがあります。

多くの企業はコーディング標準を決定し、開発者にその標準に従うことを奨励しています。
しかし、どのようにしてコードが基準を満たしていることを確認することができるでしょうか？

ESLintのようなツールを使ってコードにルールを適用することができます。
例えば、JavaScriptのコードでセミコロンの使用を強制したり、禁止したりするルールを作ることができます。
ルールを破るとESLintはエラーを表示し、コードはコンパイルされません。

Linters はカスタムルールを書くことで、標準を強制するために使うことができます。
しかし、大手テック企業が作成したESLintの設定を使って、開発者がクリーンなコードを書く習慣を身につけるのを助けることもできます。

GoogleのESLint設定はこちらで見ることができます。

ESLint はベストプラクティスに慣れるのに役立ちますが、メリットはそれだけではありません。
また、ESLintはコードのバグやエラーの可能性を警告してくれるので、よくある間違いを避けることができます。

CircleCI

継続的なインテグレーションや開発は、多くの企業がアジャイルの原則を採用していることから、ここ数年で多くの人気を集めています。

JenkinsやCircleCIのようなツールを使えば、ソフトウェアのデプロイとテストを自動化できるので、
難しいエラーが発生しやすいビルドプロセスを自分で行わなくても、より頻繁に確実にデプロイできるようになります。

ここでは製品としてCircleCIを挙げていますが、これは無料であり、JavaScriptプロジェクトで頻繁に使用されているからです。使い方も非常に簡単です。

例を見てみましょう。デプロイ/QAサーバーとGitリポジトリがあるとします。
変更した内容をデプロイメント/QAサーバーにデプロイしたいとします。

1. 変更を Git にプッシュする
2. サーバーに接続する
3. Dockerコンテナを作成して実行
4. 変更をサーバーに引っ張ってきて、すべての依存関係をダウンロードする (npm install)
5. テストを実行して、何も壊れていないことを確認してください。
6. ESLint/Sonar のようなツールを使ってコードの品質を確保する
7. すべてが問題なければコードをマージします。

CircleCIを使えば、これらの操作をすべて自動で行うことができます。
Gitに変更をプッシュしたときに、上記の操作をすべて行うように設定しておくことができます。
テストに失敗するなど、何かあった場合にはプッシュを拒否してくれます。

この記事では、各ツールの "なぜ？"について詳しく説明しているので、CircleCIの設定方法の詳細には触れません。
しかし、より多くのことを学び実際の動作を見てみたい方は、このチュートリアルシリーズをチェックしてみてください。

さいごに

最後まで読んでいただきまことにありがとうございます。

DeepLに突っ込んでいくだけでも毎日続けると英語のドキュメントへのハードルが下がるのでおすすめです！

あと記事書いたYigit Kemal Erincさんが「俺のブログのリンク貼っといてくれやで」って言ってたので貼っときます↓

https://erinc.io/

それでは！
[cv:issue_marketplace_engineer]