npmパッケージの公開を自動化するためのメモ
Github Actions Workflow to Publish NPM Packages From A Monorepo - George's Homepage
gir.me.uk
Changesets
Changesets + GitHub Actionsの連携を調べているがまだよくわからないことが多い。
Changesetsでnpmへのリリースを自動化する - ろぼいんブログ
最近、筆者が管理するいくつかのGitHubリポジトリーにChangesetsを導入しました。これによってnpmへのリリース作業を自動化でき、負担が減りました。この記事では、Changesetsを導入する手順を詳しく解説します。
roboin.io

Ditching manual releases with Changesets | Dimitrios Lytras
Hassle free versioning & changelog management with Changesets
dnlytras.com

【2023Q1】pnpm+Changesets+GitHub Actionsでmonorepo内のnpmパッケージのリリースとCodecov連携を自動化する - Qiita
概要pnpm Workspace, Changesets, GitHub Actionsを組み合わせて以下のリリースフローを構築する。開発の区切り毎に $ pnpm changeset でCha…
qiita.com

npm prepublishOnlyでビルドを呼んではいけない - Qiita
2018/02/06 追記以下の記事にpublish時の挙動について詳しくまとまっています。適宜参照するとよいです。npm prepublish の現状と今後どう変わっていくかを、表にしてまとめ…
qiita.com

package.jsonのscriptsのプレフィックスについて
pre, postをつけると前後で実行するコマンドになる。
npm-scripts の pre, post プレフィックス
zenn.dev

今日読んだ記事のメモ
今日読んで気になった記事のメモ。
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(前編)
ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しまし...
publickey1.jp

技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(後編)
ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しまし...
publickey1.jp

だから、基本的には良かれと思って既存コードとコーディングスタイルを合わせようとする。あるいは、これは善し悪しがある、まあ悪い方が多いんですけれど、機能追加の際などにレビュワーの負担を下げようとしてコードのDiffを小さくしようとするんです。
本当は、このインデントの構造を変えた方がいいんだけど、それをするとDiffが大きくなるから止めよう、とか、本当はメソッドに抽出したほうがいいんだけど、それだとDiffが大きくなるからこのif文を追加で、みたいな感じでDiffを小さくしようとする。
(GitHub上などで)Diffでコードレビューするようになったことで、Diffの小ささがよしとされてしまう。これをやや俯瞰で見ると、構造的複雑さとか命名的な悪さというのが、じわじわと累積されていく形になるんですね。
そういうのが何年も積み重なると、現場のレガシーコードが出来上がる。
レガシーコードの「命名的問題」「構造的問題」のどちらを優先してリファクタリングすると保守性や可読性が高くなるかの調査のレポート記事。引用はレガシーコードが出来上がる過程のあるあるを丁寧に文章にしてあって好きだった部分。