会計freee が yarn から npm に出戻った本当の理由

会計freee が yarn から npm に出戻った本当の理由

freee Tech Night #2

018cdfda69f5d2fbf4ddb71b5b4e1478?s=128

Ryo Ochiai

March 26, 2019
Tweet

Transcript

  1. 2.

    • 1993 年静岡生まれ • 千葉工業大学大学院情報科学専攻卒 • 学部 2 年から Web

    アプリケーションエンジニアとしてアルバイト • 内定後に長期インターンとして 1 年間人事労務freee の開発に従事 • 2018 年 に新卒として freee へ入社 ◦ 入社後は会計freee の開発に従事 • ゆるい Apple 信者 ◦ 毎年 iPhone 買ってます Ryo Ochiai @_kemuridama 落合 涼 プロダクト開発船団/会計開発船/会計ヨット 2
  2. 7.

    7 Agenda 1. yarn vs npm 2. 会計freee が yarn

    から npm に出戻った本当の理由 3. npm に出戻るまでの道のり 4. まとめ
  3. 10.

    10 npm • Node Package Manager • Node.js に内包される Official

    なパッケージマネージャ • package.json を元に必要なパッケージをインストール
  4. 11.

    11 yarn • Facebook などによって開発 • package.json 互換の Unofficial なパッケージマネージャ

    • チェックサムによるパッケージの整合性チェック • 会計freee では約 2 年前に npm から yarn に移行
  5. 14.

    14 yarn を使う 3 つの利点 1. 高速インストール • 並列インストール •

    効率的なキャッシュ 2. ロックファイル • yarn.lock による依存パッケージ のバージョン固定化 3. ワークスペース • monorepo の管理機能がデフォ ルトで実装 npm と比較して yarn が優れている点
  6. 15.

    15 1. 高速インストール • yarn は npm に比べてパッケージインストールが超高速だった ◦ yarn

    の方が 20 倍速いという結果もある • npm 5 から改良が進められて 6 ではほぼ同等の速度インストール可能に → yarn を使うメリットが少なく…
  7. 16.

    16 2. ロックファイル • package.json では依存パッケージ全てのバージョン指定はできない ◦ 環境ごとに異なる依存パッケージがインストールされてしまう • npm

    4 までは shrinkwrap によるバージョン固定化を図っていた ◦ npm install とは別に npm shrinkwrap -dev の実行が必要 ◦ -dev 付け忘れにより devDependencies の整合性の破壊 ◦ npm-shrinkwrap.json のコンフリクト解決が困難
  8. 17.

    17 2. ロックファイル • npm 5 以降は yarn.lock のような package-lock.json

    が自動生成 ◦ npm shrinkwrap のような煩雑性はなくなる → yarn を使うメリットが少なく
  9. 18.

    18 3. ワークスペース • Lerna を使えば npm でも monorepo を簡単に構成できる

    ◦ https://lernajs.io/ • そもそも会計freee でまともにワークスペースを使っていなかった → yarn を使うメリットがない
  10. 21.

    21 複数バージョンの yarn が使いにくい • yarn は基本的にグローバルインストール ◦ プロジェクト毎に異なるバージョンの yarn

    を使いづらい • freee では 1 人のエンジニアが複数のプロジェクトに関わることがある → しかし複数のプロジェクトで同じバージョンを使ってるとは限らない
  11. 22.

    22 yvm • Yarn Version Manager ◦ https://yvm.js.org/docs/overview • 複数バージョンの

    yarn を管理できるようになる • nodenv のように path を置換するものではない ◦ yvm exec hogehoge → 複数の yarn を取り扱うための銀の弾丸とは言えなかった
  12. 24.

    24 2 つのビルド環境 • CircleCI による Docker ベースのビルド ◦ テストやコンポーネントカタログを作る

    • Jenkins による通常ビルド ◦ CDN に配信するためのコードのビルド
  13. 25.

    25 ビルド環境の複雑化 • Docker ベースのビルド ◦ Dockerfile の更新、イメージ作成 ※ Node.js

    の Official Docker Image には yarn が含まれてますが freee では使っていません • Jenkins ベースのビルド ◦ Ansible の更新、サーバへの変更適用 → ビルド環境ごとに yarn をインストールするステップが増える
  14. 27.

    27 100 人を超えるエンジニア組織 2012 2013 2014 2015 2016 2017 100

    50 75 25 会計 会社設立 人事労務 マイナンバー 開業 申告 freeeカード 2018 プロダクト リリース エンジニア数(人) API公開 サービス 分割開始 マイクロ サービス化 基盤投資加 速 チーム制 導入 クラウドERP コンセプト発表
  15. 31.

    31 npm に出戻るまでの道のり • 一歩遅れていたツール群をアップデートしつつ yarn を捨てることに 1. Babel 7

    の導入 2. Node.js のアップデート 3. さよなら yarn 4. QA テスト & リリース
  16. 32.

    32 Babel 7 の導入 • 会計freee では半年弱 Babel 7 の

    Beta 版を使用 • 2018 年の 8 月の終わりに Babel 7 の正式版が出たのでアップデート • @babel/preset-env の設定にハマり IE で polyfill が漏れる不具合が発生
  17. 33.

    33 Node.js のアップデート • もともと Node.js v8.11.2 を使用 ◦ ビルド時のパフォーマンス低下が発生する可能性があった

    • 少しでもビルド時間を減らして生産性向上を図りたい → Node.js v10 LTS へアップデート
  18. 34.

    34 さよなら yarn • yarn から npm に戻す deyarn に基づいて

    npm への出戻り作業を実施 1. yarn.lock の削除 2. node_modules の削除 3. npm install を使ってパッケージを再インストール
  19. 35.

    35 QA テスト & リリース • npm と yarn では依存性解決が少し違う

    ◦ lock ファイルを再生成しているのでパッケージのバージョンがズレる • synp を使って yarn.lock を package-lock.json に変換しようと試みる → invalid になってしまってうまく行かなかった • QA テストを通すことで動作を担保することにしました
  20. 38.

    38 まとめ • 3 ヶ月ほどかけて会計freee は yarn から npm に出戻りました

    • 2019 年現在 freee において yarn より npm の方が優れている ◦ npm のインストール速度向上 ◦ package-lock.json によるバージョンの固定化 ◦ エンジニアが増えたことによる yarn の導入コストの増加 ◦ プロジェクトごとに異なる yarn のバージョン
  21. 39.

    39 今後について • 今はまだ社内において npm と yarn が混在している ◦ 実際のところ導入コストを下げるという目的は達成できていない

    → 他のプロジェクトでも脱 yarn をやっていく • Yarn v2 (Berry) の動向のチェック ◦ もしかしたら来年の Advent Calendar で Yarn に出戻りましたという記事を書 いてるかもしれません