はてなブックマーク

モノレポ管理のツールを検討したときのメモ Background 自分が所属するチームで開発する JavaScript/TypeScript のプロダクトが増えてきて、同じような内容のリポジトリがいくつも存在している（n個とする）。 変更を加えていくにつれて、それぞれの差分が大きくなり、以下のような問題が発生する。 開発が止まっているプロジェクトの構成が古くなり、修正コストが発生する 開発が複数同時進行している場合、同じような実装を手動で同期する必要がある これらは共通の基盤等があれば効率的に（理想的にはn分の1の労力で）開発が可能であり、将来的なコストを考えると、いまのうちにその仕組みを考えておきたい。 Proposed Solutions 要件は以下 複数のパッケージをnpmとしてpublishできる アプリケーションも管理できる Nx, Rush, Lerna を主要な選択肢としている

TLDR バックエンドのコードを esbuild で TypeScript 化した ビルド時間は1秒ほど tsc に比べて10倍以上高速化できた 特に問題なくプロダクションで安定稼働している esbuild はいつ使えるのか みなさん webpack は使っていますか？まだまだ広く使われていると思いますが、最近では esbuild の事例もたまに見るようになってきました。 ABEMAにesbuildを導入してWebのバンドル処理を69倍高速化した話 | CyberAgent Developers Blog esbuild が爆速すぎて webpack / Rollup にはもう戻れない | Kabuku Developers Blog 現時点で esbuild をフロントエンドの Bundler として導入するには、以下のような問題があります。 ES5にトランスパイルできない Code S

React内部で「Lane」という仕組みが用いられている。 Initial Lanes implementation by acdlite · Pull Request #18796 · facebook/react 先日React 18 alphaが発表されたが、Concurrentな機能の多くはLaneの機構をベースとしてつくられている。 Laneは、Reconcile時のタスクを32bitで表す。Laneを表す実際のコードは、例えば以下のようになる。 // https://github.com/facebook/react/blob/9212d994ba939f20a04220a61e9776b488381596/packages/react-reconciler/src/ReactFiberLane.new.js const NoLane: Lane = 0b00000000000

比較的大規模なソースコードを読む時に自分が気をつけていることをまとめます。 明確な目的をもって処理を追う 「○○の処理ってどうなってるんだろ」から始める メインの処理から順番に追っていくのは効率が悪いし骨が折れる すべてを1行1行理解するのは諦める 実際に関数の中身を読んでいく時には、後述のように全体感や依存関係を把握して、ある程度どこにどんな処理が書いてあるか当たりをつけてから読み始めたほうが効率が良い すぐにコードの詳細を読み始めるのは、いきなり応用問題に取り掛かるようなものである ただ、単純に興味があるときは、1行1行順番に追っていくのも結構楽しいのでやったりする ディレクトリ名、ファイル名を眺める 大規模なソフトウェアにはなんらかのアーキテクチャが用いられていることが多く、ディレクトリやファイル名には意図がある エントリーポイントを探す 外部向けAPIのエントリーポイント、内部向け

いまさらながらReact Fiberのアルゴリズムを実装してみました。 300行くらいですが、プログラムの名前や責務など、本物のReactをできるかぎり忠実に再現するようにしています。実装は以下にポイントを絞りました。 Fiberのデータ構造とトラバースアルゴリズム 中断可能な「Unit of work」 RenderフェーズとCommitフェーズ アーキテクチャは以下のような感じ コード上にReactのソースコードへのリンクもコメントしているので、見比べてみるとより理解が深まると思います(例えば、今回はrequestIdleCallbackで擬似的にスケジューリングを実現していますが、Reactでは独自にSchedulerをつくっています)。 Fiberのアーキテクチャに関しては既にたくさんの情報があるため、この記事ではいくつか登場人物を紹介するまでとします。 performUnitOf