{ "componentChunkName": "component---src-templates-blog-post-jsx", "path": "/post/what-about-hothouse/", "result": {"data":{"site":{"siteMetadata":{"title":"WEB EGG","author":"Leko - CTO at Yuimedi"}},"markdownRemark":{"id":"5a551b4c-bc80-50f2-9fca-f55fe400bdea","excerpt":"hothouseというツールを作成しました。 package.json とロックファイルを更新して GitHub に pull request を作成する CLI ツールです。 npm か Yarn をパッケージマネージャとして使用できます。 普通のリポジトリだけではなく、Lerna や Yarn workspaces…","html":"

hothouseというツールを作成しました。
\npackage.json とロックファイルを更新して GitHub に pull request を作成する CLI ツールです。

\n

npm か Yarn をパッケージマネージャとして使用できます。
\n普通のリポジトリだけではなく、Lerna や Yarn workspaces など monorepo の構成にも対応しています。

\n\n

概要

\n

\n \n \n \n \n \n \n \n \n

\n

こんな感じの PR が作成されます。
\n文言のベースは Greenkeeper をリスペクトしていますが、微妙にアレンジしています。

\n

実際に hothouse で出してみた PR の例をいくつか挙げると、

\n\n

こんな感じです。

\n

主な強み

\n\n

用途

\n

「Greenkeeperでいいやん」感があるのは認めます。
\nただしこのツールは Greenkeeper の障壁が上がる private repo での使用を主な用途にしています。

\n

たった数ドルお金払うだけなんですが、そこが障壁になって

\n\n

とかとかの話が身の回りにあるなーと思い、OSS の Greenkeeper 的なものを作りたいなと思いました。
\nあと純粋に技術的にどう作るのか気になったので、検証のために作ってみました。

\n

いちいち手動で実行するのではなく、CI の定期実行（cron）の仕組みに乗っけて使っていただきたいので、ガイドを整備中です。しました

\n

使い方

\n

https://github.com/settings/tokens/new
\nから新しい Github の Personal access token をrepoスコープで取得しておきます。
\nもし public なリポジトリならpublic_repoだけあれば足ります。プライベートリポジトリならrepoが必要です。

\n
npm i -g hothouse
\n

して、アップデートしたいリポジトリに移動して、hothouse -t {取得したトークン}コマンドを実行すると PR が送られます。
\nもし Git の config が設定されて入ればそれを使います。もし未設定ならhothouseという名前で commit します。

\n
git config user.name hothouse\ngit config user.email hothouse@example.com
\n

必要であれば、これらを設定してコミッターの名前を変更してください。
\nnpm の private scoped package を使っている場合には、事前にnpm loginしてから実行してください。

\n

お試し

\n

いきなり PR 作られるの怖いって場合は、--dry-runオプションをつけると副作用は起こらなくなります。
\n合わせてDEBUG環境変数を使用すると、より詳細な出力が出るので、何が起こるのか、なんとなく掴めるかなと思います。

\n
DEBUG=hothouse* hothouse --dry-run -t {取得したトークン}
\n

特定のパッケージのアップデートは無視したい

\n

アップデートのマイグレーション・心理的コストが大きかったり、package.json 上げるだけではダメなもの（react-nativeとか）は、hothouse の監視下から外す方が良いと思います。

\n
hothouse -t {取得したトークン} --ignore react-native*
\n

仕組み

\n
    \n
  1. カレントディレクトリの構成を検出
    2. \n
  2. ローカルパッケージ一覧を取得
    3. \n
  3. npm|yarn outdated からアップデート可能なパッケージ一覧を取得
    4. \n
  4. package.json に書かれている semver の範囲から外れているものだけにフィルタ
    5. \n
  5. パッケージ名ごとにグルーピング
    6. \n
  6. package.json のバージョンをいじり、プロジェクト構成ごとにコミットすべきファイルをコミット
    7. \n
  7. パッケージのバージョンから GitHub のタグ・リリースノートを取得して PR の文言を作成
    \nタグやリリースノートは取得できないこともあるので、ないことも許容
    8. \n
  8. GitHub に PR 作成
    9. \n
\n

ざっくりこんな流れで動いてます。

\n

publish された npm パッケージを Git(Hub)と紐付けたり、さらに tag やリリースノートを取得するところを地味に工夫しています。
\n命名規則に頼るなどのヒューリスティックなやり方しかできないと思っていたのですが、
\nnpm 公式で package.json の正規化などのユーティリティを提供していたり、gitHeadというプロパティがあることを知り、これをベースにヒューリスティックでない方法も模索できるようになっていました。
\nこの辺りは長くなるので、別途記事を書くと思います。

\n

マージビリティの高いプルリク

\n

マージビリティ＝マージするための心理的・レビューコストの低いオーナーに優しい PR

\n

Greenkeeper と、類似系の OSS を比べてて思ったマージビリティの違いが、
\n「PR が全パッケージのアップデート入りになっているか、パッケージ別に分かれているか」でした。

\n

例えば開発系のツール（webpack、Babel、ESLint、sinon etc）がアップデートされた場合、テストが書かれていて、CI が通ればほぼ確実にマージして良いと言えるでしょう。
\n一方、製品に使用しているライブラリは、いろいろごちゃまぜになっている場合、
\nいざアップデートしたら何が起こるか読み切れず、なかなかマージに至らないというケースがあると思います。
\n全てのパッケージの受入テストを書くのはかなり維持コストがかかるので、よほど体力があるプロジェクトでないとやりきれないかなと思います。

\n

なので、1 パッケージごとに PR を出すことで、マージするための心理的コスト、検証コストを下げ、このパッケージは merge するけど、このパッケージは closeという緩さを許容したいと思います。
\nその緩さが、可能な限り多くのライブラリが新しいバージョンになっている状態を作るんじゃないかなーと仮説を立てています。
\n（代わりに、しばらくアプデをサボっていたリポジトリで hothouse を実行すると、かなりの数の PR が飛びます）

\n

今後の動き

\n

方針は「心地よいデフォルト挙動」なので、マージビリティについて探求していきたいです。
\nあとは脆弱性の文脈で、npm@6 から追加されているnpm auditを取り入れたいなと思っています。

\n

他には、日本語だとこれくらい思いを書けるのですが README が弱いので、この記事に書いたことを README に反映していきたい。\nあと想定よりも複雑なものになったのでリファクタしたり、ドキュメント整備したりもぼちぼちやっていきます。

\n

npm パッケージたくさん抱えている CureApp に少しずつ導入してって、バグの洗い出しや使い心地の検証・改善を進めていきたいと思います。

\n

個人的によく見る構成・パッケージマネージャはサポートしたつもりなので、プロジェクト構成やパッケージマネージャの拡充はあまり考えていません。メンテコストかかるし。

\n

最後に

\n

ぜひ使ってみてください！
\n動かなかったり気に食わないところあれば、ぜひ Issue や Pull request 送っていただけると喜びます。

\n

あと、スターください

\n
\n

— Leko/hothouse: Continuous dependency update for Node.js project

\n
","timeToRead":8,"frontmatter":{"title":"package.jsonを更新してPRを作成できるCLIツールhothouseを作った","tags":["npm","JavaScript"],"date":"July 06, 2018","featuredImage":{"childImageSharp":{"fluid":{"tracedSVG":"data:image/svg+xml,%3csvg%20xmlns='http://www.w3.org/2000/svg'%20width='400'%20height='187'%20viewBox='0%200%20400%20187'%20preserveAspectRatio='none'/%3e","aspectRatio":2.141025641025641,"src":"/static/f248db553b8f2007e63b6f953a2be233/8eab8/featured-image.png","srcSet":"/static/f248db553b8f2007e63b6f953a2be233/1ec58/featured-image.png 334w,\n/static/f248db553b8f2007e63b6f953a2be233/ccb4a/featured-image.png 668w,\n/static/f248db553b8f2007e63b6f953a2be233/8eab8/featured-image.png 1336w,\n/static/f248db553b8f2007e63b6f953a2be233/b73ad/featured-image.png 1422w","srcWebp":"/static/f248db553b8f2007e63b6f953a2be233/f7e47/featured-image.webp","srcSetWebp":"/static/f248db553b8f2007e63b6f953a2be233/cd98f/featured-image.webp 334w,\n/static/f248db553b8f2007e63b6f953a2be233/7535d/featured-image.webp 668w,\n/static/f248db553b8f2007e63b6f953a2be233/f7e47/featured-image.webp 1336w,\n/static/f248db553b8f2007e63b6f953a2be233/d060b/featured-image.webp 1422w","sizes":"(max-width: 1336px) 100vw, 1336px"}}}}}},"pageContext":{"slug":"/what-about-hothouse/","previous":{"fields":{"slug":"/how-to-publish-npm-public-scoped-package-with-lerna/"},"frontmatter":{"title":"lernaでnpmにpublicなscoped packageをpublishする方法","tags":["JavaScript","npm"]}},"next":{"fields":{"slug":"/lets-start-lerna-changelog-to-easy-publish/"},"frontmatter":{"title":"lerna-changelogで始める頑張りすぎないリリースノート自動生成","tags":["npm","JavaScript","monorepo","Lerna"]}}}}, "staticQueryHashes": ["2585454260","2954598359"]}