概要

このエントリでは、小規模なWEBフロントで、作ってしばらくたったものについて、JS系のツール周りを見直す時の考え方の例について扱います。
筆者が、とある友人と会話する前に、自分でちょっと考えてみたことをダンプしたものです。

前提

このエントリでは、以下を前提とします。

• "絶対バージョンを上げられない"などの制約がない
• 変化を受け入れ、よりよいものにするにあたり、心の準備と実際に使える時間がある
• 脆弱性対応はさっさと対応、フレームワークのサポート切れに起因するアップデートも早めに対応

対象読者

• WEBフロントをメインのお仕事とはしていないが、たまに触る方
• 特定のSPA向けの「全部入り」スターターキットを使っている状態でなく、自分でツールを選んで組み合わせている方
• WEBフロントで数年って、かなり昔のことだよね、という感覚に理解がある方

ツール前提

• Nodeはエントリ執筆時点のLTS(v12.16.1)を使っています
• ツールの動作OSは問わない範囲で書いています

このエントリの版

• 2020/03/03 とりあえず初版。"テスト"のところはTODOとしておいたもの。

考え方の例

目的を設定する

「作ってしばらくたったWEBフロント」に対して何を検討したいかについて目的を設定すると、議論が進みやすくなります。

目的の例

このエントリでは、下記のような目的を想定します。

目的に対する検討タスクの例

上記の"目的例"に対して、下記のようなタスクが考えられます。このエントリでは、下表の「このエントリで扱うもの」列でチェック「x」をつけたもののみ扱います。

検討タスク例での具体例

セキュリティチェック用のツールで自分で手元で動かせるものを使ってみる

GitHubのSecurity Advisoryを使う

2019年ころから、GitHubでセキュリティチェックのためのツールが使えるようになっています(GitHubブログでの説明"Announcing Security Lab")。

確認するには、GitHubリポジトリで「Security」のタブを選択します（下図）。
下図の例で対象としたリポジトリは、筆者が2017年の春頃に書いていたコード断片です。

「Security」

Securityタブまでいかずとも、リポジトリのトップページにAlertが表示されているのでそこでも気づけます。

npm

作ってしばらくたったWEBフロントで、npm installすると、下記のようにWARNが出ていることに気づくことも多いと思います。

$ npm install
npm WARN deprecated [email protected]: 🙌  Thanks for using Babel: we recommend using babel-preset-env now: please read https://babeljs.io/env to update!
npm WARN deprecated [email protected]: Please use the native JSON object instead of JSON 3
npm WARN deprecated [email protected]: CoffeeScript on NPM has moved to "coffeescript" (no hyphen)
npm WARN deprecated [email protected]: core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.

（中略）

added 1086 packages from 1302 contributors and audited 8617 packages in 342.609s

35 packages are looking for funding
  run `npm fund` for details

found 20 vulnerabilities (4 low, 7 moderate, 8 high, 1 critical)
  run `npm audit fix` to fix them, or `npm audit` for details

上記例では「added 1086 packages from 1302 contributors and audited 8617 packages」と、いっぱいチェックしてくれていますね。

同等のチェックは、「npm audit」で確認できます。下図に実行例を示します

$ npm audit

                       === npm audit security report ===

# Run  npm install --save-dev [email protected]  to resolve 2 vulnerabilities
SEMVER WARNING: Recommended action is a potentially breaking change

  Critical        Command Injection

  Package         growl

  Dependency of   mocha [dev]

  Path            mocha > growl

  More info       https://npmjs.com/advisories/146

これを見ながらやばそうな（＝"Critical"とか"High"な）やつから順に対処を考えることにするとよいでしょう。

「npm audit fix」すると、npm auditのルールに従って、ある程度自動で利用バージョンを新しくしてくれます（下図）。semver(セマンティックバージョニング)の考え方に従って、プログラムが壊れてしまう可能性があるバージョンアップについては除外されます。

$ npm audit fix
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current:{"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\watchpack\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ [email protected]
added 2 packages from 5 contributors and updated 2 packages in 23.417s

35 packages are looking for funding
  run `npm fund` for details

fixed 9 of 20 vulnerabilities in 8617 scanned packages
  4 vulnerabilities required manual review and could not be updated
  3 package updates for 7 vulnerabilities involved breaking changes
  (use `npm audit fix --force` to install breaking changes; or refer to `npm audit` for steps to fix these manually)

さらに「node audit fix --force」すると、プログラムは壊れるかもしれないけれどもさらにライブラリのアップデートを試みます(下図)。

$ npm audit fix --force
npm WARN using --force I sure hope you know what you are doing.

> [email protected] install C:\Users\hrkt\work\shu-ho-standalone\node_modules\watchpack\node_modules\fsevents
> node-gyp rebuild


(中略)

npm WARN [email protected] requires a peer of webpack@^4.0.0 || ^5.0.0 but none is installed. You must install peer dependencies yourself.

+ [email protected]
+ [email protected]
+ [email protected]
added 172 packages from 92 contributors, removed 138 packages, updated 27 packages and moved 1 package in 35.222s

40 packages are looking for funding
  run `npm fund` for details

fixed 7 of 11 vulnerabilities in 8617 scanned packages
  4 vulnerabilities required manual review and could not be updated
  3 package updates for 7 vulnerabilities involved breaking changes
  (installed due to `--force` option)

残った部分は「npm audit」を見ながら一つ一つ対応が必要になるでしょう。

ツール類をアップデートする

目的別の分類

ツール類をアップデートにあたり、まず目的別に分類してみます。

とてもよくできたリポジトリhttps://github.com/kamranahmedse/developer-roadmap(以降"WDR2020"と略記)の「Front-end」の部分を参考に分類を試みます。例えば、下表のようになるでしょう。

「ツール類をアップデートする」という観点では、アプリに影響が大きそうなのは、各ツールがメジャーバージョンアップをし、古いバージョンとの互換性がなくなって作成したコードやスクリプト側に大きな変更が必要になるときが挙げられます。想定されるのは例えば下記のような例です。

• SPAのフレームワークがアップデートしたので引きずられていろいろ変えないと動かない
• バンドラのバージョンを上げたら使っていたスクリプトとかプラグインが動かなくなったのでいろいろ変えないといけない
• ほかの要因に引きずられてテスト実行系が壊れたので直さないといけない

このエントリでは以降、上の表でチェック「x」が入っているものについて扱います。（「N/A」としてあるものは、筆者があまり経験がなかったり、メジャーアップデートにあたり設計変更を含めた大きな変更が必要だったり、それぞれのツール/フレームワーク内でのノウハウの塊っぽかったりするので日和りました。。）

上の表で「x」をつけたものに関しては、「ツール類を見直して乗り換えてみる」も一部含みます。

各論

以降、前述の表でチェック「x」をつけたものに従い、考え方の例として、筆者の考えを述べます。判断の基準は、外部サイトを明記したもの以外は、「ソースは俺」レベルであることをお断りしておきます。

共通

まず、考え方の共通となる部分について述べます。

アップデートする/しない

• SemVerでいう、「メジャー.マイナー.パッチ」形式のバージョンでいうところの「マイナー」「パッチ」レベルなら、SemVerが主張する通りの考えで作られたツールなら、package.jsonに記載した各ツールごとにバージョンを上げて動作確認するレベルでもそのまま動作することがある程度期待できます。まれに何かが壊れることも予想されますが、そういったことが起こっても、少ない時間で対応方法が見つかる範囲にとどまることが多いと考えられます。

• SemVerでいう、「メジャー」レベルなら、多くの場合既存の資産（スクリプトとか設定）に破壊的な変更が入ることが大いに予想されます。ツールのサイトで新バージョンでの考え方・破壊的な変更点を確認することになるでしょう。親切なツールでは、移行のためのガイドが示されたりすることもあるでしょう。

乗り換えるなら

• 多くの場合、使い慣れたツールには、「学習のために多くの時間が費やされ、多少の不便があっても目の前で動いており、実現したいことに向かっての使い方がある程度わかる」という属性があるはずです。このため、「乗り換える」に、コストが見合わないことも多いはずです。このエントリは、いたずらに乗り換えを進めるものではありません。
• とはいえ、「特にこだわりもなく使い始めたが情報が少なめで不便だった」「機能的に足りないので他のツールを探したい」場合も想定されることから、本エントリではWDR2020を引用しつつ、"乗り換えるなら"案を併記します。

Module Loader / Bundler

アップデートする/しない

• このカテゴリは、ここ数年、ツールの機能追加が続いており、数年前に選択したものを新しいバージョンにすることにはメリットが多いと考えられます

乗り換えるなら

• WDR2020では、webpack押しです。そのほかの選択肢としてはParcel, Rollupがあげられています。
• webpackを現在使っているなら、webpackそのままで進めばよいと筆者は思います。機能もドキュメントもコミュニティも充実しているし。
• 上記以外の以外を使っているなら、webpackの利用の検討をお勧めします（情報量、コミュニティの活発さの観点で）

Package Manager

アップデートする/しない

• このカテゴリは、npm vs Yarnの戦いにより、それぞれがよくなっており、バージョンを上げると機能アップと、場合によっては処理が早くなる効果も期待できるので、アップデートを検討する価値はあると思います。

乗り換えるなら

• WDR2020では、npmとyarn押しです。
• npmかYarnを使っているなら、そのままの路線で筆者はよいと思います。Yarnという対抗馬が出てきたことにより、npm側も改善を入れてきているため、Yarn登場時ほどの乗り換えの圧は高くないはずです。

Task Runner

アップデートする/しない

• このカテゴリは、npm scriptsやGulpを含みます。npmなら、nodeのアップデートとともに新しいものを使っているはずです。

乗り換えるなら

• WDR2020では、npm scripts押しです。
• npm-scripts、ビルドや前処理など必要なことは一通りできるし、nodeに最初から入っているし、記述内容もシンプルでエコシステムもあるし、ということで、筆者はnpm-scriptsで十分と考えます。ほかのツールを使っていても、シンプル化のために乗り換える価値があると思います。

Testing

アップデートする/しない

• テストに関しては、自身で書いたテストケースという資産があります。テストの実行が継続的に実現できている状態なら、目的は十分果たしているため、アップデートも急を要するものではないと想定されます。

乗り換えるなら

• WDR2020的には、Jest、react-testing-library、Cypress、Enzyme押しです（筆者からみると、React系の香りがします）。一方で、WDR2020的には推奨はしない扱いのものとして、Mocha、Chai、Ava、Jasmine あたりがあげられています。
• TODO: この項目については、機会を改めてアップデートもしくは別エントリにします。（付記：WDR2020で上がっている中ではJestは使いどころが多そうであり、特定のSPAフレームワーク用にはそれを意識したツールキットが便利そうであり、E2Eをキャプチャしながら実行するのにはそれに適したツールがあり、という観点で比べるところいっぱいあって今日はおなかがいっぱい）

Linter / Formatter

アップデートする/しない

• LinterやFormatterは、ソースが綺麗に保てていることが重要であるため、言語側のアップデート対応等が必要ないのであれば急いでアップデートする必要性は低めだと思います。

乗り換えるなら

• WDR2020的には、Prettier、ESLintが一押しです。
• ESLintは、長らく広く使われているツールなので、実用上はほぼすべてのアプリで使っているのではないでしょうかと筆者はみています。Prettierは、複数の言語/IDE・エディタで使えるフォーマッタであり、ESLintと組み合わせつつの利用もできます。IDEのフォーマッタで足りている場合は必要ないかもしれませんが、CIでの利用等含めチェックをいつも行うことを考えると、使うのもよいと思います。

おわりに

このエントリでは、小規模なWEBフロントで、作ってしばらくたったものについて、JS系のツール周りを見直す時の考え方の例について扱います。

TODOにしたものは、遠からぬうちにまたエントリを書きたいと思います。