JavaScript による開発に向けて道具や環境を整えるにあたり、実に様々な用語があります。
N番煎じどころではない話題ではありますが、それらの主観的な説明を試みました。

Disclaimer:

React やその他の各種フレームワークなどは入れていません。
すべて独学、かつメチャ小規模なものばかり作っている人なので、偏りがあります。
古かったり間違ってたりしましたらぜひ教えていただければ……。
冗長な読み物感を多少含みます。
同じような or さらに詳しい情報がググれば山のようにあるので、ぜひ個別の確認を。

なお、URLを明示しないリンクは基本的に記事内で飛ぶだけで、外部リンクは基本URL付きです。

目次

一般
言語
エディター／バージョン管理
実行環境
JavaScript 標準仕様
パッケージ
コーディングスタイル
モジュール
バンドル
コードのサイズ削減
書かなかったこと

一般

当然すぎるかもしれないが前提として、みたいなの。

ツール

言葉通りの一般用語。
ソフトウェアの文脈では、汎用的な道具として利用する各種ソフトウェアの総称。

エディターのような超基本ツールのほか、JavaScript 関連でしばしば登場する例としては、
パッケージマネージャー、linter、フォーマッター、モジュールバンドラー、等々。
いずれも便利だし必要性があって生まれてきているが、いろいろありすぎて大変でもある^[1]。

ライブラリー

JavaScript の場合、各種パッケージのうち、何か他のプログラムに機能を提供することを念頭に置いて作られたもの。……と言うのは雑かもしれないし、境目は曖昧かもしれない。

プラグイン

プログラムの一種で、既存のソフトウェアの機能を拡張したり設定を変更したりする目的で追加されるもののこと。

例えば ESLint や rollup.js などに関して、公式または第三者が様々なプラグインを開発・公開している。VS Code の拡張機能を使うときにインストールするプログラムもプラグインと呼べる。

言語

JavaScript

マウスカーソルに星とかを追従させてホ～ムペ～ジに華を添えたりする言語。
というイメージがあったが、こんなに大きくなっちゃって……。

TypeScript

https://www.typescriptlang.org/

JavaScript を、静的型付けも行えるように拡張したプログラミング言語。
あるいは、その言語で書かれたコードをチェックしたり JavaScript にトランスパイルしたりする機能を提供する、公式のパッケージ（npm でインストール可能）。

静的型付けとは、特定のプログラミング言語の性質を説明するときの言葉の一つで、変数や関数の引数・返り値などについて、プログラムを実行する前から「型」が決まっていることを言う。

その恩恵は本当にいろいろあり、まず体感したほうが腑に落ちるかもしれない^[2]。
参考：『ワイ「TypeScriptなんも分からん」- Qiita』
　https://qiita.com/Yametaro/items/ee69f2f81759b9ac39b7

コードは厳しくチェックしてもらうこともできるし（可能ならその方が良い）、ゆるい設定で始めて JavaScript と変わらない状態のコードから徐々に型を追加してくこともできる^[3]。

エディター／バージョン管理

以下は JavaScript に限らず、あらゆるソフトウェア開発で広く使える。

Visual Studio Code

https://code.visualstudio.com/

代表的なコードエディターの一つ。"VS Code" とも。
特に TypeScript を使った開発とは相性が良い^[4]。

当然ながらコードを書くうえで便利な機能がいっぱいである。
また、素の状態で Git と連携してくれるほか、各種拡張機能を入れることで（エディター上で探して気軽に入れたり消したりできる）、個別に機能を足したり、各種ツール（linterとかフォーマッターとか）をリアルタイムで自動実行したりできる。

Git

https://git-scm.com/

ソースコードなどのバージョン管理システムの代表格。変更履歴を記録する。
開発に複数人が参加する際に、各々の編集内容をうまいこと統合したりするのにも使う。

一人で使う場合でも以下のメリットがある^[5]。

適切に記録していれば、いつでも過去の状態を追跡できる
VS Code などのエディターと連携すると、変更箇所・変更内容を分かりやすく表示してくれる
コードを GitHub などにアップロードして、公開したり、物置代わりにしたりできる

GitHub

https://github.co.jp/

~~怪しい設計図共有サイト~~
ソースコードなどを保存し、広く公開したり、多人数で開発したりできるサービスの代表格。
使うには Git が必要。

GitLab（https://about.gitlab.com/）など、選択肢となるサービスは他にもいくつかある。

実行環境

Webブラウザー

いま開いてるやつです。

HTML ファイルの中で <script> タグによって JavaScript のコードを読み込むことで、そのコードが動作する。

ブラウザーには数種類あり、ECMAScript への対応の進み方が一律ではない。
もし、自分の書いたコードができるだけ多くのブラウザーで動作することを望むなら、その違いを意識する必要がある。

Node.js

https://nodejs.org/ja/

ブラウザー以外で JavaScript のコードを動かすための代表的な実行環境。

Node.js で動作させるコードでは、標準で組み込まれたいろいろなモジュールを利用できる（例えばファイルの読み書きを可能とするfsモジュール）。逆にブラウザー特有の機能は使えない。

モジュールシステムについて、主に CommonJS 形式を採用しているため、ブラウザーでは動かないrequire()関数が多用される。

……以上からすると、ブラウザーで動かすコードを書きたいだけの人からは、一見して無縁に見えるかもしれない。
しかし、Node.js 自体に含まれている npm を始め、各種有用なツールを動作させるための実行環境として Node.js が必要なため、実際は JavaScript を書く人の多くがお世話になる。

JavaScript 標準仕様

ECMAScript

JavaScript の標準仕様。ソースコードをこう書いたらこう動く、というのを取り決めたもの。
念のため：　ここで標準（standard）とは、あちこちで独自に取り決めを作ってしまうと不便なのでそれを避けるべく、これに統一しようぜ！　みたいな雰囲気を醸し出している取り決めのこと。

何度も改版を重ねており、中でも特に大幅に拡張されたのが、ES5 の次の ES2015 である。

実際に JavaScript のコードを解釈して動かすのは各種実行環境（ブラウザーや Node.js）なので、どの環境でどの版までが有効なのかは一律ではない。
『Can I use...』（https://caniuse.com/）というサイトで、個別機能ごとのブラウザー対応状況を確認できる。

参考：『JavaScriptとは · JavaScript Primer』https://jsprimer.net/basic/introduction/

ES5

ECMAScript 5th edition の略。2009年公開。

昔広く使われていた（そして今もちょっと生き残っている）Internet Explorer というブラウザーは ES5 までしかサポートしていない。逆に、ES5 に則ったコードなら大抵の環境で動く。
そこで、ソースコード自体は好きに書きつつ、最終的には ES5 にトランスパイルしてから公開する、というムーブが広まった。Chrome や Firefox などのブラウザーで動けば十分という場合は、トランスパイルするにしても、必ずしも ES5 まで落とさなくても良い。

開発効率やバグ予防の観点では ES2015 以降の仕様を活用したほうが良いので、なんの文脈も無い状態で新たにコードを書くのなら ES5 までのことは忘れたほうが良い。とは言え、昔書かれた ES5 のコードはたくさん残っているし、簡単には捨てられない面もある。

ES2015

ECMAScript 2015 の略。ES5 の次なので ES6 とも。
参考：『ECMAScript - Wikipedia』https://ja.wikipedia.org/wiki/ECMAScript

const、let、class、アロー関数、その他多数の重要な文法が追加されており、ES5 以前のコードと ES2015 以降のコードはひと目で分かるくらい違う。
よりシンプルかつバグりにくいコードが書けるので、状況が許すなら積極的に使いたい。
参考：『ES2015(ES6) 入門 - Qiita』https://qiita.com/soarflat/items/b251caf9cb59b72beb9b

トランスパイル

ソースコードを別の形のコードに変換（transpile）すること。
JavaScript の文脈では、次のいずれか（または両方）の意味で使われることが多い。

比較的新しいバージョンの ECMAScript に則って書かれた JavaScript のソースコードを、安定動作のため、より古いバージョンの ECMAScript に合うように変換する（ES5 も参照）。
TypeScript など、JavaScript の標準に則っていないソースコードを、目的の環境で実行できるように、標準的な JavaScript のコードに変換する。

いずれも、安定的に動作する JavaScript のコードを自分の手で書く必要はなく、好きな仕様で書いてから最後に帳尻合わせれば良い、みたいな発想という点では同じである^[6]。

パッケージ

JavaScript の場合、いくつかのモジュールを一まとめにしたもののこと^[7]。

一般的な概念としては、よし、ちょっとなんか作るぞ、と思ってまずフォルダーを作ったとして、まあ、場合にもよるが、そのフォルダーの中身全体のことだと思って良い（大作だったり関係性の薄いものがあれこれ入っていたりするのなら分離しよう）。

JavaScript なら多くの場合 npm や類似のパッケージマネージャーで管理するので、そのフォルダーの中には package.json が存在するはずだ。

パッケージマネージャー

パッケージのメタ情報や依存関係などを管理したり、パッケージの公開やインストールを補助したりするツールの総称。

世界中の人の手によって、無数のパッケージが公開されており、ライセンスの許す範囲で自由に利用できる。しかし個別にポチポチとダウンロードしたりしていては大変だし、それぞれバージョンも上がっていくので、どこでどのバージョンを使うのか気を配らなければならない。そういったことなどを引き受けてくれる。

JavaScript において代表的なのは npm だが、その欠点を補うべく yarn や pnpm といった選択肢も第三者によって開発されている。

JavaScript に限らずあらゆるソフトウェアのインストールや管理をする、Homebrew や Scoop などといったツールも同じく「パッケージマネージャー」と呼ぶが、ここでは置いておく（そちらも便利なので別途調べると良い）。

npm

JavaScript における代表的なパッケージマネージャー。

Node.js に含まれており、Node.js をインストールした時点で、コマンドラインで npm コマンドが使えるようになる。
参考：『CLI documentation - npm docs』https://docs.npmjs.com/cli/

自分が開発中のパッケージのディレクトリーの中に package.json というファイルを置いて、そのパッケージに関するメタ情報や設定などを記録する形で利用する。
例えば、そのパッケージが依存する他のパッケージの一覧をバージョン込みで記録・管理して、それらを一括自動インストールできる。結果、それらのパッケージ内のモジュールがエクスポートしている機能を自分のソースコードの中でインポートしたりできる。

また、同名の公式オンラインリポジトリーがあり、これを指すことも多い。
外部のパッケージをインストールするとき、基本的にはここで公開されているものがダウンロードされることになる。
https://www.npmjs.com/

yarn

https://yarnpkg.com/

npm の代替となるパッケージマネージャー。

オリジナルの npm には速度・バージョン整合性・ディスク容量消費量などといった点で改善の余地があり、それらを改善するべく開発された。その後 npm 自体の改善も追いついてきたためメリットは以前よりも相対的に薄れたが、今なお広く使われている。

pnpm

https://pnpm.js.org/

npm などの代替となる後発のパッケージマネージャー。

背景として、npm で外部のパッケージをインストールするとき、自分の開発するすべてのパッケージで共通して使えるようにする「グローバルインストール」と、個別のパッケージごとの「ローカルインストール」が選べる。
汎用的に使えるパッケージはグローバルインストールするのも悪くないが、バージョン整合性の観点や、自分の各パッケージでどのツールが必要なのかを明に管理したいことなどを考えると、やっぱり基本はローカルインストールとしたい。
しかしそうすると、おびただしい数のファイル群をパッケージごとにインストールすることとなり、時間がかかるし、ディスクスペースがかなりもったいない^[8]。

pnpm は、見かけ上は従来のパッケージマネージャーと同じように動きつつ、インストールしたパッケージ群の実体は一箇所で一元管理する。よって無駄なダウンロードやファイルコピーを極力行わない。ついでに、依存関係が複雑な場合に整合性が取りにくくなる問題も解決する（らしい）。

難点は qwerty 配列で「pnpm」とタイプするのがめんどくさいことである。

コーディングスタイル

linter

主にバグの予防を目的として、ソースコードを機械的にチェックしてくれるツールの総称^[9]。

バグの温床となりうるような行儀のよろしくないコードを検知して知らせてくれたり、可能であれば自動で修正してくれたりする。

ESLint

https://eslint.org/

代表的な linter。npm でインストール可能。

細かくルールを設定できるが、recommended なルール郡を一括適用して手軽に始めるも良し。
参考：『ESLintのルールを全部手動で設定するのは大変だからやめておけ』
https://qiita.com/khsk/items/0f200fc3a4a3542efa90

ESLint に怒られながらコードを書く過程で、推奨されるコードの書き方が自然に身につく……かもしれない。
一時的にルールを破りたいときには、指定の形式でコメントを書くことで部分的に無効化できる。

なお TypeScript と併用するにはそれ用のプラグインが必要。

コードフォーマッター

ソースコードを自動で整形してくれるツールの総称。

整形というのは、例えば空白の有無、セミコロンの有無、どこで改行するか……などといった、主に見た目に関する部分について、統一的なルールを適用すること。

Prettier

https://prettier.io/

代表的なコードフォーマッター。npm でインストール可能。

特徴としては opinionated であること。つまり「特定のルールを押し付けないから自分で細かく設定してね」ではなく、「これが我々の推奨するルールだッ！」という雰囲気でデフォルト設定が決まっている。特に何も設定せずに使っても、開発元が推奨するとおりのコードスタイルにできる。
どうしても変えたいところがあれば設定変更もできる^[10]。

なお JavaScript/TypeScript 以外にも様々な言語に対応している。

eslint-config-prettier

ESLint 用のコンフィグ（設定）の一つ。npm でインストール可能。
ESLint を Prettier と併用するときに使う^[11]。

もともと ESLint にはバグ予防だけでなくフォーマッターとしてのコード整形機能も入っているが、コード整形についてはそれを専門とする Prettier に任せる方法が主流となりつつある。
しかし ESLint と Prettier を一緒に使うと、コード整形のルールが衝突して編集合戦みたいになるので、ESLint 側のコード整形機能をオフにしたい。
これを手動でやる場合、ESLint 側の設定ファイル（eslintrc）の rules のところで該当するルールを個別に off にしていくことになるのだが、面倒なので一括でやってほしい……というのをやってくれるのがこいつである。

モジュール

何らかのシステムやプログラムの構成単位として利用されることを意図した、小さなプログラムのまとまり。その名の通り「部品」を意味する。
少なくとも開発段階では、でかいファイルに長々とコードを書くよりも、機能ごとに小さく部品化してそれらを組み合わせるような作り方のほうが、作りやすいし第三者から見ても分かりやすい。

粒度に関して、JavaScript/TypeScript においては、基本的には1つのソースコードのファイルが1つのモジュールだと思って良い。ただし、いくつかのモジュールを置いたディレクトリーの中に index.js などを置いておくと、そのディレクトリー自体が1つのモジュールとして振る舞う、という感じになっていることも多い^[12]。

あるモジュールの内容をエクスポートし、それを他のモジュールでインポートすることによって、モジュール間の依存関係が生まれる。モジュールシステムも参照。

なお、それ単体で完結し、インポートもエクスポートもしていないようなソースコードファイルは、ふつうモジュールとは呼ばず、単に「スクリプト」と呼んだりする^[13]。

エクスポート

ある JavaScript のモジュールの中にある何らかの値を、他のモジュールから使われることを意図して公開すること。
ここで「値」とは、プリティミティブ値、関数、クラス、その他オブジェクトなどなんでも。

TypeScript の場合、値だけでなく型エイリアスやインターフェイスも対象となる
（例： export type NumberOrString = number | string;）。

インポート

ある JavaScript のモジュールの中で、他のモジュールによってエクスポートされている値を読み込むこと。

モジュールシステム

モジュールを定義したり利用したりするにあたって開発者は何をすればよいのか、また実行環境側はそれをどのように解釈・実行するべきなのか、といったモジュール周りの仕組みを策定したもの、あるいはその実装。

ECMAScript での標準化が遅めだった経緯もあって、ESモジュール、CommonJS、IIFE など複数の選択肢があり（IIFE はシステム化以前の古典的方法という雰囲気だが）、ちょっと面倒なことになっている。

インポートやエクスポートを、ソースコードの中で具体的にどうやって書くのか……というのがモジュールシステムによって変わってくる^[14]。

ESモジュール

ES2015 で策定されたモジュールシステム。ECMAScript modules の略。
"ES modules"、"ESM"とも。
いろいろあったが今後これでやっていこうみたいな雰囲気がある。

エクスポートは次のように export 文を使う。

// my-module.js
const doSomething = () => { /* 何かを行う */ };
export { doSomething };

インポートは次のように import 文を使う。
import * as myModule from '...'; のようにモジュールごとインポートしても良い。

// my-script.js
import { doSomething } from './my-module'; // 同じディレクトリーにあると仮定
doSomething(); // 何かが行われる

TypeScript でも（基本的には）同様の文法となる。
Node.js では先に CommonJS ライクな方式を採用したのが定着していたため不便が生じているが、最近徐々にESモジュールにも対応できるようになってきた。

また最近のブラウザーでは、ESモジュールのファイルをバンドルせずにブラウザー上でそのまま動かすこともできる。
参考：『JavaScript モジュール - JavaScript | MDN』
https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Modules

CommonJS

ブラウザー以外の環境における JavaScript の仕様について策定したもの。
また、その策定プロジェクト。

もともとブラウザーで動かすための言語として発達した JavaScript だが、サーバーとかコンソールとか、ブラウザー以外の環境でも使えるようになったほうが嬉しい、みたいな動機である。

なかでも重要なのはモジュールシステムの部分。
例えばエクスポートのときには

// my-module.js
function doSomething() { /* 何かを行う */ }
exports.doSomething = doSomething;

のようにして、このモジュールをインポートするときには require() を使う。

// my-script.js
var myModule = require('./my-module.js'); // 同じディレクトリーにあると仮定
myModule.doSomething(); // 何かが行われる

現代で CommonJS が話題に出るとき、多くの場合は CommonJS そのものというより、上記を元にした Node.js 版のモジュールシステムのことを指している、と思って良い^[15]。

なおエクスポートに限っては、ブラウザー向けのコードでもこれを採用していることがある。
というのも、ESモジュールが登場する前は他のモジュールシステムしか選択肢が無かったため、Node.js で実行するつもりが無くても、利用者が後でうまいことバンドルする前提で CommonJS 形式（大抵はそれ以外も兼ねた UMD）によるエクスポートを行っていたのである。
いきなり全部をESモジュールに直すわけにもいかないので、今でもそうなっているライブラリーは珍しくない。

IIFE

Immediately Invoked Function Expression（即時実行関数式）の略。
関数を括弧で包んで、宣言と同時に実行する書き方。
参考：『IIFE (即時実行関数式) - MDN Web Docs 用語集』
　https://developer.mozilla.org/ja/docs/Glossary/IIFE

モジュールシステムの文脈で IIFE と言うときは、モジュールのコード全体を IIFE で包み、インポートやエクスポートに相当することをグローバル変数を介して行う、という方式のことを指す。

例えばエクスポートは、公開したい対象をまるごとオブジェクトに入れたりして関数から return させ、それをグローバル変数に入れる。

// my-module.js
var myModule = (function () {
  function doSomething() { /* 何かを行う */ }
  return { doSomething };
})();

インポートは、あらかじめ上記のようにしてエクスポートしてあったグローバル変数を、インポート側の IIFE を書くときに引数で渡す。

// my-script.js
(function (myModule) {
  myModule.doSomething(); // 何かが行われる
})(myModule);

これを HTML ファイルの中で順番に読み込めば、それぞれのスクリプト間ではグローバル変数が共有されるので、全体が無事に動作する。

<script src="my-module.js"></script> <!-- グローバル変数 myModule が利用可能になる -->
<script src="my-script.js"></script> <!-- それをこの中で利用する -->

わざわざ IIFE で包む理由は、そうしないと各種変数が何でもかんでもグローバルになってしまって、互いに余計な影響を与えてしまいかねないからであり、モジュールごとの影響範囲を限定するためにこうしている。

ふつう手動でこのようなことはやらないが、各種ライブラリーにおいては、モジュール郡の全体をバンドルしたものを IIFE 形式（あるいはそれ以外も兼ねた UMD）にまとめ、それを公開していることも多い。利用者はそれを上記 HTML のように読み込んで手軽に利用する、ということが広く行われている。

UMD

モジュールの定義方法の一つ。Universal Module Definition の略。

IIFE 形式を踏まえつついろいろ小細工を加えた関数でコード全体を包む。
これにより実行された環境に応じてカメレオンのごとく振る舞いを変え、IIFE の項のようにグローバル空間に吐き出したり、CommonJS や AMD^[16] のやり方でエクスポートしたりする。

バンドル

複数のモジュールファイルについてインポート／エクスポートの関係を読み取り、依存関係にあるモジュール群の全体を一つのファイルにまとめあげること。
バンドルした結果できるコードは、それ単体で動くかもしれないし、別の新たな（大きな）モジュールかもしれない。

主にブラウザー環境で動かすコードを作る過程でこれを行う。
ESモジュールまたは IIFE 形式のモジュールであれば、バンドルせずモジュールごとに <script> タグを書いてロードというのも可能だが、いくつも書いて個別にロードするのやだなぁとか、ロードの順番を間違えちゃうからイヤとか、そういったアレがある。

そこで、開発中はソースコードを細かいモジュールに分割して書きつつ、最終的にはバンドルしてからブラウザーで動かす、ということがよく行われる。

モジュールバンドラー

その名の通り、モジュールをバンドルするためのツールの総称。

ついでに treeshake したり、特定の ECMAScript のバージョンにトランスパイルしたりと、いろいろやってくれることが多い。

webpack

https://webpack.js.org/

CAUTION: rollup と並べるために置いたが webpack エアプです

代表的なモジュールバンドラーの一つ。npm でインストール可能。

JavaScript のファイルだけでなく、CSS やら画像やらも含めていろいろやってくれる。名前に Web と付くとおり、WebサイトやWebサービスをまるごと作る用途などで広く使われる。

rollup.js

https://rollupjs.org/

代表的なモジュールバンドラーの一つ。npm でインストール可能。

特徴：

かなり大きな仕組みである webpack などに比べると比較的スリムである。
モジュールシステムに関して、ESモジュールを基本とする。
比較的きれいなコードを生成してくれる傾向がある（という意見を見かける）。
使い分けについて “webpack for apps, rollup for libraries” などと言われたりもしている。
ライブラリーに限らず小規模なパッケージや、バンドル対象ファイルが *.js/*.ts だけのパッケージなどに向いていると思われる。

ただし TypeScript ファイルのバンドルはデフォルトでは行えずプラグインが必要になる。
そのプラグインがいくつかあって、どれが良いのか分かりにくかったり、微妙に動作が安定しなかったりするのが惜しい。
最悪、TypeScript のtscコマンドなどで *.ts を全部 *.js にトランスパイルしてから rollup でバンドルするという逃げ道もある。

コードのサイズ削減

デッドコード削除

ソースコードの中で使われていない（削除しても影響がない）部分を、機械的に検知して削除すること。

tree shaking

JavaScript のモジュールをバンドルする過程でデッドコード削除を行うこと。

バンドルすることによって、各モジュールがエクスポートしている機能のうちどれが本当に必要なのかが判明するため、このタイミングで削除する。
……という意味を踏まえると、tree を shake するというのはそういう比喩なんだというのが分かる気もするのではないか。

ESモジュールに比べて他のモジュールシステムでは機械的な検知が難しくなるため、バンドル元のモジュールはESモジュール形式で作っておいたほうが恩恵に預かれる。

minify

JavaScript のコードや CSS のファイルなどを、文字数が極力少なくなるように加工すること。

空白文字やコメントを削除したり、変数名を短くしたり、より短い記法ができるように組み替えたり、デッドコード削除を行ったりすることでコードを圧縮する。

主に、Webページで読み込むデータの量を少なくして表示速度を上げる目的でこれを行う。

ファイルの命名については慣例があり、例えば元のファイルが my-script.js なら、minify 後は my-script.min.js のように名付ける。

terser

https://terser.org/

Javacript のコードを minify してくれるツールの代表格。
npm でインストール可能。

書かなかったこと

筆者がまだよく分かってないので書かなかったものリスト

タスクランナー
テストフレームワーク
Babel（トランスパイラー）
React（なんかすごい）、その他各種フレームワーク
WebAssembly/Wasm（ブラウザー上で高速動作する低水準プログラミング言語）
WebGL（GPU使ってブラウザーでグラフィックス高速描画する技術）
Electron（JS等のWeb技術でデスクトップアプリを作れるフレームワーク）
その他、Web・サーバー・ネットワーク・データベース・セキュリティー関連の諸々
新興系
- Svelte（Web用フレームワーク。React 無しで生成物がコンパクト）
- Deno（Node.js をいい感じに作り直そうとしている）
- esbuild（爆速モジュールバンドラー兼minifier）
- swc（爆速トランスパイラー）
- dprint（爆速フォーマッター）

脚注

JavaScript 界隈、ツールがいろいろ乱立しすぎだろという批判も散々言われていて、例えば Rome (https://rome.tools/) のように全部乗せの最終形態を作ろうぜみたいな動きもあるけれど、統一が果たされるのはまだ先であろう。
参考：『大統一 Node ツールチェイン Rome の野望現状の実装』
https://mizchi.dev/202008101816-ambitious-rome ↩︎
型推論と言って、わざわざ明記せんでも分かるやろみたいな箇所についてはコンパイラーが型を推論して決めてくれる仕組みがあるが、昔の静的型付け言語ではあまりそういうことをしてくれなかったため、冗長なコードを書かねばならないケースが多々あった。その種の面倒くささは現代では相対的に減ったと思って良い。 ↩︎
JavaScript から入った人が TypeScript を始めるときは「コードに型を付ける」という発想になるのが普通かもしれない。しかし逆に、まず設計があり、型があり、具体的なコードはそれに沿って後から埋めていくのだ、と考えてみるのも良い。型を中心として骨組みを作れば、あとはエディター様とコンパイラー様が導いてくださる（個人差があります）。 ↩︎
VS Code 自体も TypeScript で作られている。 ↩︎
Git は極めて有用だが、初学者が使い始めるときのハードルもちょっと高めかもしれない。 ↩︎
JavaScript へのトランスパイルを前提とした言語として、CoffeeScript (https://coffeescript.org/) というのがあった。今ではあまり使われなくなってしまったが、JavaScript 周りの文化に大きく影響を与えたものとして記録（？）に残っている。なお、TypeScript や CoffeeScript のような JavaScript 代替言語を総称して altJS と言う。 ↩︎
（追記）Deno のスタイルガイド（https://deno.land/manual/contributing/style_guide）では、モジュールとパッケージを呼び分けずにすべてモジュールと呼びましょう、となっている。元より対して細かい定義もないので、これはこれで賢明かもしれない。 ↩︎
npm でインストールしたパッケージは node_modules というフォルダーに保存されるが、これは小規模開発においても簡単に数千ファイル・数百MBとなる。→『Heaviest Objects In The Universe | reddit』https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/heaviest_objects_in_the_universe/ ↩︎
lint/linter などの語があまりカタカナで定着していないのでここではアルファベット表記とした。参考：『lint - Wikipedia』https://ja.wikipedia.org/wiki/Lint ↩︎
Prettier においても「文字列を囲むときにダブルクォートよりシングルクォートを優先したいんだが」みたいな話はいまだに議論されているようだ（https://github.com/prettier/prettier/issues/4102）。 ↩︎
ESLint と Prettier の併用に必要なプラグインとして、もう一つ eslint-plugin-prettier というのがあったのだが、こちらは状況の変化などもあって最近非推奨となった。
参考：『Prettier と ESLint の組み合わせの公式推奨が変わり plugin が不要になった』https://blog.ojisan.io/prettier-eslint-cli ↩︎
ディレクトリーをモジュール扱いすると便利な面もあるが、Node.js の作者は、これはあまり良くなかったと思っているようだ。→『Node.js における設計ミス By Ryan Dahl』
https://yosuke-furukawa.hatenablog.com/entry/2018/06/07/080335） ↩︎
「スクリプト」はモジュールを含めた総称と捉えて良いが、ESLint の設定の sourceType みたいに、モジュールでないものだけを指す場合もないでもない。 ↩︎
ここでは複数のモジュールシステムを共通の構造で見渡すために「インポート」「エクスポート」という言葉を使っているが、文脈次第なところがあるかもしれない。例えば英字で "import" と書いてあるとき、ESモジュール形式の import 文だけを指すかもしれない。 ↩︎
歴史的な経緯もあって Node.js のモジュールシステムと CommonJS は同一視されがちだが、別に完全準拠ではないようだ。
参考：『Node.jsとCommonJSについて』http://meso.hatenablog.com/entry/20110626/1309082158 ↩︎
モジュールシステム AMD については本稿では書いていないし、筆者もよく分かっていない。
参考：『JSエコシステムぶらり探訪(6): AMDとモジュールローダー - Qiita』
https://qiita.com/qnighy/items/0c3fd208e0356fa19cda ↩︎

Discussion