leaysgur's Blog
leaysgur.github.io/
PrettierのExperimental CLIについて
Prettierのバージョン3.6から、Experimental CLIが利用可能になった。これにより、CLIのパフォーマンスが向上し、特に遅延ロードにこだわった設計がなされている。CLIは、--experimental-cliオプションまたは環境変数PRETTIER_EXPERIMENTAL_CLIで有効化でき、エントリーポイントはdynamicImportを使用している。ファイルのパースやプラグインのロードを行い、標準入力からフォーマット対象を決定する。設定ファイルのフィルタリングやキャッシュの準備も行われ、最終的にフォーマット処理が実行される。全体的にシンプルで読みやすい構造になっているが、設定ファイルに関する問題が多く見受けられる。 • Prettier 3.6からExperimental CLIが利用可能になった。 • CLIのパフォーマンスが向上し、遅延ロードにこだわった設計がされている。 • --experimental-cliオプションまたは環境変数でCLIを有効化できる。 • CLIはファイルのパースやプラグインのロードを行う。 • 標準入力からフォーマット対象を決定し、設定ファイルのフィルタリングやキャッシュの準備を行う。 • フォーマット処理はPromise.allSettled()でまとめて実行される。 • 設定ファイルに関する問題が多く、Issueも多く見受けられる。
oxlintに`--type-aware`オプションがきた
この記事では、Oxlintに新たに追加された`--type-aware`オプションについて説明しています。このオプションにより、TypeScriptの型情報を利用したルールが動作するようになり、具体的にはtypescript/no-floating-promisesなどのルールが実装されています。Oxlintは、内部的にTypeScriptのGoリライトであるtypescript-goを使用しており、tsgolintを子プロセスとして実行します。現在利用可能なルールは40種類あり、これらはすべてOxlintで使用可能です。記事では、Oxlintのバイナリのエンドポイントや、tsgolintプロセスとのやり取りの方法についても詳しく説明されています。 • Oxlintに`--type-aware`オプションが追加され、TypeScriptの型情報を利用したルールが動作するようになった。 • 具体的なルールにはtypescript/no-floating-promisesなどが含まれる。 • Oxlintはtypescript-goを使用しており、tsgolintを子プロセスとして実行する。 • 現在利用可能なルールは40種類で、すべてOxlintで使用可能。 • Oxlintのバイナリのエンドポイントやtsgolintプロセスとのやり取りの方法が説明されている。
OXCのASTに詳しいMCPサーバーを作った
この記事では、Rustを用いてOXCのASTに関するMCPサーバーを実装した経験が述べられています。著者は、ローカルで動作するMCPサーバーの実装を行い、OXCのASTの構造や内容を理解するためのツールを作成しました。このツールは、コード片をASTに変換し、生成されたコードのシンタックスが有効かどうかをチェックする機能を持っています。また、RustのSDKを調査した結果、いくつかの選択肢があり、最終的に動作するrust-mcp-sdkを選択しました。実装は比較的シンプルで、特に詰まることはなかったと述べています。 • OXCのASTの構造を理解するためのMCPサーバーをRustで実装した。 • コード片をASTに変換し、シンタックスの有効性をチェックする機能を持つ。 • RustのSDKを調査し、動作するrust-mcp-sdkを選択した。 • 実装はシンプルで、特に問題は発生しなかった。 • async関数をtraitとして実装する際の注意点についても言及している。
特定のcrateで公開されてるstructとenumを列挙する
この記事では、特定のcrateで公開されているstructとenumを列挙する方法について説明しています。まず、ソースコードを直接見る方法や、docs.rsを利用する方法が提案されていますが、どちらも一覧性に欠けると指摘されています。次に、rust-analyzerを使う案も考えられましたが、具体的な方法が不明でした。最終的に、cargo rustdocを使用してcrateを指定し、JSON形式で出力する方法に辿り着きました。この方法はnightly版のRustが必要で、unstableなオプションを使用することになります。出力されたJSONは大きく、構造が分かりにくいため、AIを活用して整形するスクリプトが作成されました。最終的に、必要な情報が整形され、目的のデータが得られたことが報告されています。 • 特定のcrateで公開されているstructとenumを列挙する方法を探求している • ソースコードやdocs.rsを利用する方法は一覧性に欠ける • rust-analyzerを使う案も考えたが具体的な方法が不明 • cargo rustdocを使用してcrateを指定し、JSON形式で出力する方法に辿り着いた • 出力されたJSONは大きく、構造が分かりにくいためAIを活用して整形した • 整形されたデータが最終的に得られた
`ratatui`と`tokio`で作るTUIの基本
この記事では、Rustの`ratatui`と`tokio`を使用してターミナルユーザーインターフェース（TUI）を作成する方法について説明しています。具体的には、ASTビューワーを作成し、OXCでパースしたASTを表示する機能を持つアプリケーションの実装が紹介されています。`ratatui`はTUIのコンポーネントを提供し、`crossterm`はキーボード入力や描画を管理します。描画はメインループ内で行われ、非同期処理には`tokio`が使用され、UIの応答性を保つために重い処理は非同期で実行されます。また、`ratatui`の新機能や、非同期キーイベントの処理方法についても触れられています。 • Rustの`ratatui`と`tokio`を使用してTUIを作成する方法を解説 • ASTビューワーを作成し、OXCでパースしたASTを表示する機能を実装 • `ratatui`はTUIのコンポーネントを提供し、`crossterm`はキーボード入力や描画を管理 • 描画はメインループ内で行われ、非同期処理には`tokio`が使用される • 重い処理は非同期で実行し、UIの応答性を保つ • `ratatui`の新機能や非同期キーイベントの処理方法についても言及
Cloudflare Workers Tech Talks in Kyoto #1 に行ってきたメモ #workers_tech
Cloudflare Workers Tech Talks in Kyoto #1では、Cloudflare Workersを利用した様々な技術的な発表が行われた。Claude CodeによるAstroブログのPagesからWorkersへの移行が紹介され、MCPを活用した移行ガイドも提供された。バイブコーディングとバイブデプロイの概念が提案され、CloudflareのMCPを用いたデプロイ方法が説明された。また、Scala NativeをCloudflare Containersで動かす方法や、WebSocketを利用したアプリのデプロイについても言及された。最後に、AIを活用した新しいAPIの開発や、Cloudflareを利用したデータの監視方法についても触れられた。 • Cloudflare Workersを利用したAstroブログの移行方法が紹介された。 • MCPを活用した移行ガイドが提供され、ダウンタイムなしのCNAME切り替えの課題が言及された。 • バイブコーディングとバイブデプロイの概念が提案され、CloudflareのMCPを用いたデプロイ方法が説明された。 • Scala NativeをCloudflare Containersで動かす方法が紹介され、Dockerコンテナの利用が可能であることが説明された。 • WebSocketを利用したアプリのデプロイ方法や、AIを活用したAPIの開発についても言及された。
Astroで動的なパスの画像を扱う
この記事では、Astroを使用して動的なパスの画像を扱う方法について説明しています。特に、MDXを使用したContent collectionsからサムネイルをエクスポートする方法が紹介されています。MDX以外のデータソース（CSVやJSONなど）を使用する場合、画像のパスを管理するためにAstroまたはViteに画像を認識させる必要があります。具体的には、import.meta.globを使用して画像のパスを取得する関数を作成し、.astroファイル内でその関数を利用する方法が示されています。このアプローチにより、Promiseを返す関数を使用して画像をリスト表示することが可能になります。 • MDXを使用した場合、Content collectionsからサムネイルをエクスポートできる。 • CSVやJSONなどのデータソースを使用する場合、画像のパスを管理する必要がある。 • import.meta.globを使用して画像のパスを取得する関数を作成する。 • Promiseを返す関数を使用することで、.astroファイル内で画像をリスト表示できる。 • imgタグを使用する場合は、特別な設定が必要になる。
100 Exercises To Learn Rust をやった
この記事では、Rustプログラミング言語の学習を目的とした「100 Exercises To Learn Rust」の演習を通じて得た知見を共有しています。特に、整数オーバーフローの扱いやオペレーターのトレイト、トレイト境界、型変換のトレイト（FromとInto）、およびライフタイムの省略について詳しく説明しています。また、トレイトの実装における型の取り扱いや、impl Traitの使用方法についても触れています。これらの演習を通じて、Rustのトレイトシステムや型システムの理解が深まったことが強調されています。 • Rustの整数オーバーフローはデフォルトでdebugビルドでのみパニックすることを学んだ。 • オペレーターのトレイトを実装することで、==や<などのオペレーターが使用可能になる。 • トレイト境界の理解が深まり、where句の使い方に慣れてきた。 • Fromトレイトを使うことで型変換が容易になることを実感した。 • impl Traitの使用により、関数の引数や戻り値の型を柔軟に扱えることが分かった。
AstroでPDFファイルからルートを生成したい
この記事では、Astroを使用してPDFファイルからルートを生成する方法について説明しています。PDFファイルを/publicディレクトリに置くことで、getStaticPaths()を利用してファイルを探し、個別のルートをリダイレクトまたはfetch()で処理する方法が提案されています。しかし、/publicディレクトリは混沌としがちで、あまり推奨されません。そこで、[id].pdf.tsというファイル名でエンドポイントを作成し、PDFをビルド後のアウトプットに持っていくワークアラウンドが紹介されています。具体的には、PDFファイルを読み込み、HTTPレスポンスとして返す処理が示されています。 • PDFファイルからルートを生成する方法を解説 • getStaticPaths()を使用してPDFファイルを探す手法 • /publicディレクトリの使用は推奨されない • [id].pdf.tsファイルを作成してエンドポイントを立てる • PDFファイルをビルド後のアウトプットに持っていくワークアラウンドを紹介 • PDFをHTTPレスポンスとして返す処理の実装方法
2025年前半の振り返り
この記事では、2025年前半の技術的な取り組みや進捗について振り返っています。特に、Next.jsとAstroの比較を行い、Astroが主戦場であることを強調していますが、動的なページが必要な場合にはNext.jsも選択肢として考えられると述べています。また、Prettierの移植作業やBiome Formatterの再利用に関する挑戦についても触れ、RustのASTに関する作業やTypeScriptのASTフォーマットへの対応についても言及しています。最終的には、OXCがPrettierのプラグインとして利用可能になったことを報告し、ASTの並列確認ツールの開発やパーサーのパフォーマンス向上に向けた取り組みも紹介しています。 • Next.jsとAstroの比較を行い、Astroが主戦場であることを強調 • Prettierの移植作業において、Rustへの移植を断念しBiome Formatterの再利用を検討 • TypeScriptのASTフォーマットへの対応を行い、OXCがPrettierのプラグインとして利用可能に • ASTを並列で確認できるツールを開発し、パーサーのパフォーマンス向上に取り組む • OXCのASTがESTreeに対応するための作業を進める
CSSの`::highlight()`が、Firefox 140に実装されてた
CSSの`::highlight()`セレクタがFirefox 140に実装され、特定のテキストをハイライトする機能が追加された。ただし、text-decorationやtext-shadowはまだフルサポートされていない。CSS Custom Highlight APIを使用することで、任意の部分にCSSを適用でき、DOMを変更せずにハイライトが可能になる。具体的なコード例として、Svelteを用いたエラーコードのハイライト方法が示されており、特定の文字列に対してハイライトを設定する方法が解説されている。さらに、Syntaxハイライトを行うライブラリも紹介され、実用性が増していることが述べられている。 • CSSの`::highlight()`がFirefox 140に実装されたが、text-decorationとtext-shadowは未対応。 • CSS Custom Highlight APIを使用することで、特定のテキストをDOMを変更せずにハイライトできる。 • Svelteを用いたエラーコードのハイライトの具体例が示されている。 • 特定の文字列にハイライトを付ける方法が解説されている。 • Syntaxハイライトを行うライブラリが紹介され、実用性が増している。
RustのType Stateパターンについて
この記事では、RustにおけるType Stateパターンについて解説しています。Type Stateパターンは、状態をそれぞれの構造体として定義し、ジェネリクスを用いて状態ごとに異なる実装を行う手法です。具体的には、Open、Closed、Lockedという状態を持つDoor構造体を例に、PhantomDataを使用して状態を管理する方法が示されています。また、状態ごとの共通の実装を持ちつつ、特定の条件で分岐する方法も紹介されています。さらに、Type Stateパターンをより宣言的に実装するためのライブラリも紹介されています。 • RustのType Stateパターンは、状態を構造体として定義し、ジェネリクスで管理する手法である。 • PhantomDataを使用して状態を管理し、コンパイル時に消える特性を持つ。 • 状態ごとに異なる実装を行うことで、コードの可読性と保守性が向上する。 • 共通の実装を持ちながら、特定の条件で分岐する方法も提案されている。 • TypeIdによる比較はランタイムコストがかかるため、traitを使用することが推奨される。 • 状態遷移をより宣言的に書くためのライブラリが存在する。
続・TypeScriptの`Diagnostics`について
この記事では、TypeScriptのDiagnosticsに関する効率的なエラーコードの仕分け方法について探求しています。著者は、TSCのDiagnosticsにおいて、構文エラーを特定し、型エラーや設定関連のエラーを除外する方法を模索しています。最初に、エラーコードを基にした仕分けを試みましたが、エラーコードの区別が曖昧であるため失敗しました。次に、Diagnosticsを定義しているファイルからエラーカテゴリのコードを抽出するアプローチを検討しましたが、AST全体が対象となり、コンテキストを考慮できない問題がありました。最終的に、rollupを使用してバンドルし、必要なDiagnosticsのみを取得する方法を提案しています。 • TypeScriptのDiagnosticsにおける構文エラーの特定方法を探求している。 • 型エラーや設定関連のエラーを除外するための効率的な仕分け方法を模索している。 • エラーコードを基にした仕分けが曖昧であるため、別のアプローチを検討している。 • rollupを使用してバンドルし、必要なDiagnosticsのみを取得する方法を提案している。 • 最終的に、バンドルした結果として151のDiagnosticsがスキャナーとパーサーで使用されていることが確認された。
TypeScriptCompilerのベースラインとテストの仕組み
この記事では、TypeScriptのテストケースとそのベースラインの管理方法について詳しく説明しています。TypeScriptリポジトリ内のテストは、npm run testコマンドを実行することで開始され、ここから依存タスクが解決され、テストが並列で実行されます。テストランナーは、./src/testRunner内にあり、run.jsとしてビルドされます。テストは、CompilerBaselineRunnerを使用して実行され、テストケースはtests/cases/conformanceおよびtests/cases/compilerディレクトリから取得されます。各テストファイルは、特定のコンパイラ設定に基づいて解析され、テストが実行されます。 • TypeScriptのテストはnpm run testで実行される。 • テストは依存タスクを解決した後、並列で実行される。 • テストランナーは./src/testRunnerにあり、run.jsとしてビルドされる。 • テストはCompilerBaselineRunnerを使用して実行され、2種類のテストがある。 • テストファイルは特定のコンパイラ設定に基づいて解析される。
TypeScriptの`Diagnostics`について
この記事では、TypeScriptの`Diagnostics`に関する考察が述べられています。TypeScriptコンパイラ（TSC）の構文エラーと意味エラーの分類について、特に`tsProgram.getSyntacticDiagnostics()`と`tsProgram.getSemanticDiagnostics()`の違いが議論されています。著者は、構文エラーとして報告されるべき事例が意味エラーとして扱われることに疑問を呈し、TSCのパーサーがどのようにエラーを分類しているのかを探求しています。また、TypeScriptリポジトリ内でのDiagnosticsの処理方法や、エラーコードの管理についても触れています。さらに、テストケースを用いてパーサーの出力を検証する方法についても言及されています。 • TypeScriptの構文エラーと意味エラーの分類に関する考察 • `tsProgram.getSyntacticDiagnostics()`と`tsProgram.getSemanticDiagnostics()`の違い • TSCのパーサーがエラーをどのように分類しているかの探求 • Diagnosticsの処理方法とエラーコードの管理について • テストケースを用いたパーサーの出力検証方法の提案
sveltejs/esrap のコードを読む
この記事では、Svelteコンパイラで使用されるライブラリ「esrap」について詳しく解説しています。esrapは、AcornでパースしたASTを文字列に戻す役割を担っており、特にJSとTSのASTの文字列化が可能です。ただし、JSXや一部のTypeScriptノードのサポートが不完全であることが指摘されています。また、ソースマップやコメントの出力に対応しているものの、コメントの挿入には事前の準備が必要です。実装はシンプルで、APIも簡潔ですが、TypeScriptの型サポートが中途半端である点が懸念されています。類似のライブラリとして「astring」が紹介されており、こちらはより簡素な実装で拡張性があります。 • esrapはAcornでパースしたASTを文字列化するライブラリである。 • JSXや一部のTypeScriptノードのサポートが不完全である。 • ソースマップやコメントの出力に対応しているが、コメントの挿入には事前準備が必要。 • 実装はシンプルで、APIも簡潔である。 • TypeScriptの型サポートが中途半端であることが懸念される。 • 類似のライブラリとして「astring」があり、こちらは拡張性が高い。
JSX/TSXのASTを、できる限り元のコード文字列に戻したい
この記事では、JSX/TSXのAST（抽象構文木）を元のコード文字列に戻すための実装パターンについて調査しています。特に、ESTree、TS-ESTree、Babel、SWC、TypeScriptなどの異なるASTを選択することが重要であり、それによって後続のツールも決まることが述べられています。コードをパースしてASTを取得するためのライブラリとして、oxc-parser、acorn、meriyah、@typescript-eslint/typescript-estree、@babel/parser、@swc/core、typescript、ts-morphなどが紹介されています。また、BabelやSWCを使用したコード生成の方法や、コメントの復元についても触れられています。特に、@babel/generatorが信頼性が高く、コメントの対応も行われていることが強調されています。最後に、ASTを変更するAPIの複雑さやパフォーマンスの懸念についても言及されています。 • JSX/TSXのASTを元のコード文字列に戻すための実装パターンを調査している。 • ESTree、TS-ESTree、Babel、SWC、TypeScriptなどのASTの選択が重要である。 • コードをパースしてASTを取得するためのライブラリが複数紹介されている。 • BabelやSWCを使用したコード生成の方法が説明されている。 • @babel/generatorが信頼性が高く、コメントの復元にも対応している。 • ASTを変更するAPIの複雑さやパフォーマンスの懸念が指摘されている。
`import type { A }`と、`import { type A }`の違いで、Viteのチャンク配分が変わることもある
この記事では、`import type { A }`と`import { type A }`の違いがViteのチャンク配分に与える影響について説明しています。具体的には、`parseSync()`の実装がバンドルに含まれることで、エントリーポイントである`index.js`が重くなる問題が発生することが示されています。`import { type A }`を使用すると、意図しないバンドル結果が生じる一方で、`import type { A }`を使用することで期待通りの結果が得られることが確認されました。また、`oxc-parser`がCJSで書かれているため、tree-shakeされない可能性も指摘されています。 • `import type { A }`と`import { type A }`の違いがViteのチャンク配分に影響を与える。 • `parseSync()`の実装がバンドルに含まれることで、エントリーポイントが重くなる問題が発生する。 • `import { type A }`を使用すると、意図しないバンドル結果が生じる。 • `import type { A }`を使用することで期待通りの結果が得られる。 • `oxc-parser`がCJSで書かれているため、tree-shakeされない可能性がある。
GitHub Pagesでも`SharedArrayBuffer`を使いたい
この記事では、GitHub Pagesで`SharedArrayBuffer`を使用するための条件とその解決策について説明しています。`SharedArrayBuffer`は、セキュリティ要件の厳格化により、特定の条件を満たさないと使用できません。具体的には、HTTPSであり、crossOriginIsolatedなドキュメントである必要があります。これを実現するためには、特定のHTTPヘッダー（Cross-Origin-Opener-PolicyやCross-Origin-Embedder-Policy）を付与する必要がありますが、GitHub Pagesではこれを直接設定することができません。そこで、`gzuidhof/coi-serviceworker`というライブラリを使用することで、ServiceWorkerを介して必要なヘッダーを追加する方法が提案されています。このライブラリは、シンプルなユースケースでは問題なく動作することが確認されています。 • `SharedArrayBuffer`を使用するためには、HTTPSかつcrossOriginIsolatedなドキュメントである必要がある。 • 条件を満たさない場合、`SharedArrayBuffer`はグローバルに存在しない。 • 必要なHTTPヘッダーを付与するためには、CloudflareやNetlifyなどのカスタムヘッダーを設定できる環境が必要。 • GitHub Pagesでは特別なファイルやGUIがないため、直接ヘッダーを設定することができない。 • `gzuidhof/coi-serviceworker`ライブラリを使用することで、ServiceWorkerを経由してCOI関連のヘッダーを追加できる。 • このライブラリは、シンプルなユースケースで問題なく動作することが確認されている。
`@typescript-eslint/typescript-estree`をブラウザで動かし、型チェックもやる
この記事では、`@typescript-eslint/typescript-estree`をブラウザで動作させ、型チェックを行う方法について説明しています。TypeScriptのASTを生成するために、まずファイルをTSCでパースし、型チェックが必要な場合はTSのプロジェクトを用意してDiagnosticsを取得し、それをESTree形式に整形するという2段階の処理が必要です。ブラウザでの動作は簡単ではなく、既存のライブラリやツールを活用することが推奨されています。特に、`@ts-morph/bootstrap`を使用することで、少ないコードで型チェックが可能になります。最終的に、TS ASTをTS-ESTreeに変換し、表示する方法も紹介されています。 • TypeScriptのASTをブラウザで動かすための手法を解説 • 型チェックを行うための2段階の処理が必要 • ブラウザでの動作は簡単ではなく、既存のライブラリを利用することが推奨される • `@ts-morph/bootstrap`を使用することで、簡単に型チェックが可能になる • TS ASTをTS-ESTreeに変換する方法も紹介されている
`@typescript-eslint/parser`と`@typescript-eslint/typescript-estree`の関係
Letters from Andrew Ng / Agentic Design Patterns のまとめ
TypeScriptのテストファイルの読み方
TypeScriptのASTにおける`JSDocXxxType`というノード
`Bun.serve()`だけでルーターが書けるようになってた