nodeパッケージマネージャーの管理をcorepackに移行した&設定メモ

前置き

この記事は2023-02-18 corepack@0.16.0 時点でのメモです

🚨 corepackの進化に伴いこの記事は陳腐化する可能性が高いです。

移行した

Node.js自体はasdfで管理しているのだけど、npmはnodeに付いてくるやつを使いyarnとpnpmはhomebrewで粗雑にインストールしていた。

corepackがそういえばあったなと思って、一応Node.js14以降にはexperimentalとして標準搭載されているしそろそろ使うかと思って移行した。

corepackについては以下が詳しい。

zenn.dev

ようはnpmとかyarnとかpnpmのようなnodeパッケージマネージャーのマネージャー。マネージャーinマネージャー。

corepackはnode18とかだともうexperimentalとはいえ標準でenableになっているのでnodeが動く環境なら corepack コマンドのPATHが通っている。

取り急ぎ yarn と pnpm と一旦サヨナラをする。

brew uninstall yarn pnpm

corepackで管理するとコマンドが冗長になる問題

グローバルな存在のpnpmをインストールしないようにするゆえ、これまで pnpm install とかやってたのが corepack pnpm install になる。しんどすぎる。

corepack run みたいなことできるようになりたいという npm script 絡みのIssueがあるけど色々ありそう。

Feature request: corepack run · Issue #57 · nodejs/corepack · GitHub

エイリアスでごまかす

corepackを通してパッケージマネージャーの実体を解決するから、自分でPATH通そうにもダルいし、なんとなくそのうちcorepack自体がなんとかする気がするからエイリアスでごまかすことにした。

alias pnpm='corepack pnpm'
alias yarn='corepack yarn'
alias cleancache:corepack='rm -rf ~/.cache/node/corepack/'

fishシェルの config.fish に雑に書く

そして package.jsonpackageManager のフィールドが

"packageManager": "pnpm@7.27.1+sha1.75c15a7a16389531192dab282e45aacdac1ed4c0"

こんな感じに書かれているリポジトリ

pnpm -v とかやると

gyazo.com

パソコンの中にpnpmがどこにも入ってなくても、ちゃんと 7.27.1 のバージョンのpnpmが現れて動いてくれる。

実際は corepack pnpm -v したことになって、corepackくんは packageManager のフィールドを参照してキャッシュを見に行って該当するものがあったらそれを。なかったらシュッと必要なバージョンを用意してくれている。

自分の環境だと ~/.cache/node/corepack が現場なのでここにウニョっと生える。

gyazo.com

ちなみに cleancache:corepack については、現状corepackを通じて管理されるpnpmの実体バイナリをお掃除するコマンドがないので雑に用意している。

クリーンキャッシュのコマンドが欲しいというIssue自体はある(corepack cleanup cache · Issue #114 · nodejs/corepack · GitHub)。

packageManagerフィールドに書くハッシュどこ

READMEにはハッシュまで書くのを推奨している がcorepackがこれを出力することは2023-02-18現在のv0.16.0ではできない。

これに関してもIssueがある。

Feature request: instructions on how to determine the hash for the `packageManager` field in `package.json` · Issue #231 · nodejs/corepack · GitHub

Issueにcorepackのciスクリプトの参照がある。今の所ガンバリじゃないと取れなさそうではある。

2024-04-05追記: corepack usecorepack up というコマンドがいつのまにか生えていたのでこの問題は解決していた。


余談

corepackを使わない環境で『npm | pnpm | yarn コマンドが煩雑すぎる問題』を解決したい人はこういう便利ツールもある。

npm、yarn、pnpmに直接PATHが通っている環境で「このリポジトリは…… yarnか」「ここは……pnpmか…」みたいなことを避けたい人は ni コマンドでなんも考えなくてよくなるので便利。

github.com

アジャイル開発のアジャイルとはなにか? について喋った

喋る機会があったのでアジャイルの本質を伝えたくて喋った。せっかくなのでブログにしておく。

speakerdeck.com

お気持ち

アジャイル開発を実践するあたって、いきなりスクラムとかリーンとかについて学んだりしても効率が悪いと思っている。順番が逆で、それよりも前提として「アジャイル開発のアジャイルとはなにか?」を理解して腹落ちしてないと手法やフレームワークの掲げる正論に振り回されて、一向に改善のサイクルが回らない状態に陥ってしまうと感じている。

エンジニアリングの本質が「問題解決」であり「不確実性を削ること」と捉えられるかどうかで日々の思考や物事への向き合い方が変わると思っているので、この前提を飛ばしたくない。

チームは誰かひとりの所有物ではなくて、メンバーの一人ひとりで構成されたみんなの物だと思っている。誰かひとりがアジャイルマインドを持っていても一人でアジャイルを推進するのではすぐ限界がやってくる。みんなで日々の営みの捉え方を揃えてみんなで推進しなければ改善のサイクルは回らないし、うまくいかない可能性を減らせない(うまくいくかわからないという不確実性が削れない)。

ウォーターフォールアジャイル

アジャイルよりウォーターフォールのほうが向いている開発となるケースもある。一概にアジャイルだけがいいというわけではない。以下のような場合はウォーターフォールのほうが向いている可能性がある。

  • リソースが潤沢
    • 人的リソース
    • 金銭的リソース
    • 情報的リソース
    • 物質的リソース(工場のような生産ラインのリソース含む)
  • 作るものが計画しやすくプロジェクトの開始時ガッチリ決められるもの
  • 計画が外的要因による変更が起こりにくい場合

端的に言うと「不確実性と戦う必要がない場合」はアジャイルである必要がないので、対比するとウォーターフォールのほうが効率がよくスピードも早い場合がある。

例えばすでに開拓された市場へ新規参入するような場合で必要な機能や改善点が明確であり、サービスカット時に競合優位性を確実に付けることが必要な場合。

組み合わせる戦略

すでに開拓された市場へ新規参入するような場合で、必要な機能や改善点が明確であり、サービスカット時に競合優位性を確実に付けることが必要な場合。

「競合優位性を付ける」の部分が不確実性を持っている。本当に競合優位性を付けられるかわからない場合もある。こういう場合は、明確に計画できる部分の開発はウォーターフォール的にガッと進めて、不確実性のある部分の開発だけアジャイル開発をするのでもいいと個人的には思う。

アジャイル開発において、イテレーションの連続により不確実性が減っていく様子を小さな滝と捉える人も一部いてミクロな視点でみると確かにそうも見える(実際には軌道修正をするので小さな滝の連続ではないと個人的には思うが)。でもこういう捉え方のほうがイメージしやすい気持ちもわかるし、実際ケースバイケースでこういう捉え方で進めるほうが組織に合っていてプロジェクトが成功するのならそれでいいと思う。

計画の有無

アジャイル開発の誤情報のスライドページには書かなかったけど、「アジャイル開発は計画しない」という誤解を持っている人がたまにいる。そんなわけはなくてアジャイル開発でも計画性は必要。計画なしにどうやって「このイテレーションでなにを達成するのか」を決められようというのか。

アトラシアンのアジャイルのページにタスク粒度の話がある。

www.atlassian.com

Initiative(テーマと呼ばれたりもする)という大きめの目標や達成すべき機能があって、それはどこからやってくるかというと、事業計画のロードマップからドリルダウンして作成される。

Roadmapを達成するために達成すべきInitiativeがあり、Initiativeを達成するために達成すべきEpicがあり、Epicを達成するために達成すべきTaskがある。だからイテレーションでなにをすべきかがわかるわけで、計画がなかったらスーパーマンが勘でやるべきこと決定することになる。

ちなみに計画の立て方や柔軟性や調整については、最近読んだ以下のブログがわかりやすかった。

tech.mti.co.jp

CCPMの考え方はすごくいい。スコープに対してやることを調整する方向がアジャイル開発においてはよいと思う。

アジャイル開発でうまく行かないパターンとして、「スコープに対してやることを調整しない(デスマーチ化する)」か「やることを調整せずスコープを調整する(お尻を伸ばす)」がある。前者の場合は不確実性と向き合わず削りきれなかった事実とも向き合わない状態で、後者はタイムボックスを伸ばして不確実性を削りきれなかったことをなかったことにしようとしている。


クソ真面目すぎる内容で困るので、もっとふざけた記事を今年は書いていけるといいな。