最近になって Frontend Ops の傭兵として活動を始めました。 Frontend Ops 実践のモデルケースとして、 株式会社GiXo様で Next.js 仕事に取り組ませいただきました。今回、その内容を公開する許可を頂けたので、事例として公開させていただきます。 依頼主 株式会社GiXo様 以下、敬称略 相談内容 フロントエンド関連のリポジトリで、Next.js のビルドが遅くなってしまった。 重いことに起因して Vercel CI で OOM で確率的に落ちるようになった。CIが信用できなくなり、とりあえず再ビルドするクセがついてしまって、生産性が落ちている。 モノレポ内にとくに重いアプリケーションが一つあり、これを調査・解決してほしい。 仮ゴール: VercelCI 上のビルド時間を半分OOM が発生しないようにしたい 調査フェーズ リポジトリの閲覧権を頂き、プロジェクト構成

みんなお世話になっている TypeScript のコードを読みたいと思ったことはないだろうか。読んだ。 一週間ぐらいかかった。完全に読み切ったとは言えないが、概要は掴んだ。 なかなかに複雑でドメイン知識を得るのが難しかったので、これから読む人向けに、登場人物や概念を整理して紹介したい。 読んだのは 2023/6/8 時点で git clone したコード。 最初に: 自分のゴール設定 複数ファイルにまたがった参照を、 TypeScript の Language Service が提供する findReferences() や findRenameLocations(), goToDefinitions() を使って、インクリメンタルに書き換えたかった。 Terser を使うと、今触ってるオブジェクトが何で、何のメンバを書き換えたかの情報が残らない。これを TypeScript のレイヤーで

いまさら気づいたけど Headless 系のUIライブラリが一番 AI と相性いいのではないか。 ロジックはプログラマで書けて自由度高いし、コンポーネントのネスト構造から意図を読み取れるだろうし、class 名は自由に書けるから意図を表明しやすい。 それをプロンプトとして ChatGPT or Codex にそのまま投げて書かせる、ができる。 というわけで vite + react + radix-ui + vanilla-extract で実験してみた。 プロンプト あなたは凄腕のマークアップエンジニアです。 radix-ui は Headless UI ライブラリで、UIとしてのセマンティクスのみを持っています。 次のコードは React + radix-ui + vanilla-extract で書かれた React コンポーネントです。 // Popover.tsx import

プログラミング学習とはそもそも何なのか プログラミング初学者やITに関わる人が最初に知るべきこととして、プログラミングとは「あなたが問題を解決するのに用いたい手段を、あなたが思っているようにコンピュータに入力すること」ではない。 実際には、プログラミング学習はコンピュータに可能な(非常に限定された)処理セットを学ぶことであり、その応用の先に当初のゴールが含まれるかは、プログラミングを学んでその特性を学ばないと、判断すらできない。 例えば、手段 A によってゴール X を達成したいとしよう。非プログラマ/プログラミング初学者の発想は、よほど目の付け所がいいのではない限り、次のいずれかに分類される。 A には同じゴール X を解決する簡易な代替手段 B があり筋が悪い。 A で実現するほどの価値がない A は現状の人類の既存のソフトウェアの応用では実現できない。あるいは非常に困難。無理に実現し

まだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん…。 Announcing D1: our first SQL database Cloudflare D1 = Edge SQLite Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか？ 僕はヤバいと思いました。 このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。 Durable Objects は CDN 上の Actor モデルを構築できます。この Acto

JS で wasm のダウンロードや TypedArry を通じた操作をやってると、コード内や localStorage にバイナリを埋め込みたいときがあります。 考え方 JS の内部エンコーディングは UTF16 と決められているので、UTF16で表現可能な範囲を1文字として、バイナリをインライン化すればサイズが小さくて済むはず Chrome は CompressionStearm でブラウザ内で deflate できるので、あれば圧縮する https://chromestatus.com/feature/5855937971617792 Chrome ではない場合、deflate 処理は飛ばしてそのまま。localStorage の読み書きなら途中でブラウザ自体のサポート増える/消えるなどしない限り一貫性は取れる 今回はやってないが、インラインJSに埋め込む場合、50kb を超えたあた

この本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl

自分も教える事が多いので、読み手にどういう風に学んでほしいか、自分がどういう風に伝えるべきか、という視点で読んだ。 1章・イントロダクション そもそもTypeScript とはなにかみたいな話。 コンパイルエラーが出ている状態ではプログラムが完成したとは言えません。 力強い コンパイルエラーをただ避けるのではなく、利用する気持ち で TypeScript プログラミングに臨みましょう。 初心者に型違反の向き合い方を諭す話。IDEの補助になるとか。 TS年表で取り上げてるのが特徴的。exactOptionalProperty を取り上げてたり。 TSの型はランタイムに影響しない、という話を何度も解説している。これは初心者の誤解がとても多いので、必要だと思う。何度いっても、伝わって欲しい人に伝わらないのだが… enum や namespace については意図的に解説しない。過去のTS独自路線だ

Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho

ビルドサイズ限界まで絞りたい人向け。 あらゆる環境で実践するものではないが、知ってたら簡単に避けることができるのもあるので知っておくと便利なTIPS書いていく。 基本ポリシー 未使用コードはビルド時に全部落とす。 何が未使用コードで、何が定数かわかるようなインターフェースを人間が心がける。 用語 Dead Code Ellimination(DCE) Rollup や Terser で、未使用コードを削除すること

自分が欲しかったから作ったシリーズ 説明しづらいので下記の動画を見たほうが速いです。 Shift を押している間だけオーバレイが有効になり、要素名をクリックすると vscode の該当行に飛びます。 今のところ vite + react のみの対応ですが、仕組み上、あらゆる UI フレームワークに適応可能です。 何が起きているか TypeScript transformer の仕組みで *.tsx の jsx 要素に data-sj-path="vscode://file/..." を付与する TypeScript AST は sourcemap 用の情報を持っている Node の parent を探索し、直近の関数コンポーネント名を探す Shift を押している間、 マウスでホバーされた要素が data-sj-path を持っているならオーバレイを表示 オーバレイ中の要素名をクリックした

実際、コード量に比例して遅くなります。 これは tokenize のステップがなく、すべての構文ルールが正規表現を個別に実行するのが遅い理由でした。またそのせいで空白制御のために構文定義が冗長になっていました。 そのため、事前に tokenize ステップを用意し、pargen を事前に分割された token 列を受け取るパーサコンビネータとして再実装しました。(元の pargen はあれはあれで使いやすいので別実装になってます) mints v0.1 の ベンチマーク 試した環境は MacBookPro M1 Max 64GB です。 --------- 2416chars [tsc] 58ms [esbuild] 14ms [mints] 6ms [mints_para] 12ms --------- e2981chars [tsc] 14ms [esbuild] 1ms [mints

この記事は、既存のCSSのレイアウトの文脈ではなく、「プログラムから制御されるレイアウト」をいかに綺麗に制御・生成するか、です。 複雑なSPAや何らかのオーサリング環境で、主に JavaScript の視点からレイアウトを扱うのに Grid をどう活かしていくか、という話。 grid-template-areas の視覚的な対応 IEがない世界では CSS grid のフル機能を使うことができます。 自分が grid を使う際、今まで grid-template-areas を気に入って使っていました。これは CSS の視覚的な情報が最終的な表示と一致する、という理由からです。 例えば、 svelte で書いた grid-template-areas を使ったレイアウト設定のコードはこんな感じになります。。 <div class="grid"> <div style="grid-area:

tl;dr ファイルをそれ単独で単体テストとして実行するボイラープレートを編み出した そのヘルパとして mizchi/test という実装を作った なぜソースコードにテストを書きたいか Rust や Python の doctest ではソースコードにテストを書く方法があります。 ソースコードにテストを書けると、コードとテストの心理的な距離が近くなってテストが書きやすくなる、という肌感があります。(諸説あります) 実装とテストが混ざって汚れるのが嫌という意見も理解できますが、それはありつつ認めた上で、あとでリファクタする前提で最初の一歩をその実装に書けると嬉しい、という気持ちがあります。 現状の Node だととりあえず assert するだけという単純なテストを書くことは可能ですが、構造化する方法がないので、簡単なスクラッチの時ぐらいしか行われません。 // test.js import

tldr; ES2018 の named capture group を活用することで、 簡易なパーサジェネレータを 1kb 切るサイズで実装できた。ただし正規表現の表現力に縛られているので、再帰はできない。 完成形 https://github.com/mizchi/flat-pargen named capture group を pegjs 風に活用したい ES2018 以降の JavaScript の正規表現では、 (?<Name>...) で正規表現の実行結果に名前をつけることができます。 > new RegExp("(?<a>x)(?<b>y)").exec("xy").groups [Object: null prototype] { a: 'x', b: 'y' } start = additive additive = left:multiplicative "+" ri

ロマン構成が動いたので紹介します。 コード: https://github.com/mizchi/absurd-sql-example-with-typeorm デモ: https://heuristic-perlman-94f8f4.netlify.app tldr Steam の某クリッカーゲームをやってたら放置ゲーでも作りたい気分になってきた。 複雑なデータを管理するならブラウザ内に本物の sqlite を持ってきたい sqlite は持ってこれたけど TS の中で 生 SQL 書くのがだるかった(補完支援がない)ので ORM でラップしたい Typeorm + absurd-sql の構成を試したら色々大変だったけど動いた つまりブラウザでこのコードが動く。 // ... @Entity() class User { @PrimaryGeneratedColumn() id: nu

超巨大フロントエンドを分割する基盤を作ろうとしたものの紹介します。 この記事の前提 巨大フロントエンドを分割統治したい SSR は考えない モダンブラウザのみ対応する(IE11 非対応) この記事では single-spa とマイクロフロントエンドの紹介はしません。こちらの記事を読んでください。 マイクロフロントエンド入門 single-spa でマイクロフロントエンドを検証する - mizdev single-spa はアプリケーションのライフサイクルに簡単な規約を導入するもので、おそらく一番使われてるものです。これを基本的に vite と組み合わせて各アプリケーションを構成しますが、 webpack でも同様のことは可能です。 動いてるもの デモ ここで実現したこと 共通ヘッダ 異なる環境でビルドされたコンテンツをルーティングごとに切り替える react-router のアプリと vu

DnD は考えることが多い。大抵のライブラリは特定のユースケースにべったりで、毎回自分で書く羽目になる。 とくに、木構造の DnD をどう表現するかが難しい。特にWeb上でファイラーのようなUIを実装する頻度が高く、その求められる実装が毎回違うので、自分が考えていることを一般化してみる。 この記事はコードをコピペしたら使えるものではなく、あくまで考え方をコードに落としたもの、ということに注意。 今回は前提として、こういうものを作っていた。 DnD の要件 DOM ベースの sortable ライブラリはいっぱいあるが、DOMをマスターデータとして扱うタイプが多く、現代のフレームワークと噛み合わない。可能な限りデータを元に表現して、最後に変更したデータを render するだけとする。 フレームワーク非依存な処理を切り出して、UIを通さずにテストを書いたり、ポータブルに扱えるようにしたい。

これは monaco-editor で作られたエディタを操作してるサンプルです。 アイデア 複雑な SPA を同じページ内部で動かそうとすると、主にビルド方法や相対パス周りで問題が発生します。例えば vite と webpack で噛み合わなかったり、monaco-editor のように暗黙の loader を大量に設定する必要がある場合だったり、デプロイされた場所のどういう相対 URL でモジュールを解決するか、です。 このうち、部分的に複雑なコンポーネントを埋め込む場合(例の monaco-editor がそうです)、古の iframe widget のアプローチでこれを解決できるのでは、と考えました。また実際に手元で発生していた問題で、とある画面でコンパイラ一式を埋め込んで rollup のビルド結果をプレビューする、という機能がプロジェクト全体を重くしてしまった、というのがありまし

stackblitz が提唱して実装している node.js が動くブラウザ環境。container といってるが、 Docker 等とは関係ない。 stackblitz/webcontainer-core このコンテナはブラウザ内で node.js (らしきもの)が動くことがターゲットで、現在デモとして next.js をビルドしてプレビューできている。これによって node.js + webpack + next.js cli が動いていることがわかる。 デモはここで試せる。 まだ OSS ではないので、この記事の大部分は想像によって書かれている。 webcontainer 概要 (自分の理解なので話半分に) ブラウザサンドボックスでも electron なしでも動かせるようになってきた。しかし現在 node.js を動かすには色々と欠けている部分があるので、それらを総称して webc