RhodoniteというWeb3Dライブラリを作っています。最近はRISV-VやOS開発などにも興味が。多趣味で不器用です。

Today we are excited to announce the availability of TypeScript 5.9 Beta. To get started using the beta, you can get it through npm with the following command: npm install -D typescript@beta Let’s take a look at what’s new in TypeScript 5.9! Minimal and Updated tsc --init Support for import defer Support for --module node20 Summary Descriptions in DOM APIs Expandable Hovers (Preview) Configurable
Analyzing code similarity... === Function Similarity === Checking 142 files for duplicates... Found 8 duplicate pairs: ------------------------------------------------------------ Similarity: 89.09%, Score: 8.0 points (lines 9~9, avg: 9.0) src/utils/getUserById.ts:4-12 getUserById src/utils/findUserById.ts:8-16 findUserById Similarity: 88.00%, Score: 14.1 points (lines 15~17, avg: 16.0) src/servic
TypeScript ツールチェインは多種多様で、毎回目的に沿ってプロジェクトを設定するのが非常に大変です。 なので、再現性のある環境構築手順を作って LLM に丸投げすることにしました。 (この記事の7割はAIに書かせて、自分で30分かけて書き直しました) tl;dr Claude Code に読ませる前提のTypeScriptの環境構築ガイドラインを作った docs/ts-guide/ にドキュメントを配置して、LLM(Claude)にそれを読ませる プロジェクトの要件を伝えて、LLMに適切な設定を追加させる ベースラインとなる基礎部分から始めて、対話的に必要な機能を追加していく How to use すごい雑に実態を説明すると共通セットアップとただのライブラリの使い方のドキュメントです。 # 新しいプロジェクトを作成 mkdir my-app cd my-app # ts-guide
はじめに こんにちは、ARCH チームの立川です。 今回が初めてのテックブログになります。 先日、社内で「条件分岐をスマートに評価する」というテーマで、TypeScript(JavaScript)における条件分岐の書き方について発表する機会がありました。古いコードに触れる中で、見通しの悪い記述を多く見かけることがあったため、発表に至った経緯があります。 この記事では、その発表内容をベースにコードの可読性を高める条件分岐のテクニックをご紹介します。基礎的な内容ではありますが、少しでも役立つヒントがあれば幸いです! 三項演算子をよりスマートに使うためのヒント 三項演算子は非常に便利ですが、状況によってはもっとシンプルで読みやすい代替手段があります。ここでは、等価な三項演算子と比較しながら、それらの方法を紹介します。 null 合体演算子( ?? )を活用する null 合体演算子は、左辺が n
プロトタイプ開発環境というのは、雑に思いついたwebアプリを素早く作成するための環境のことで1年半くらい前にもこういう記事を書いた。 個人開発やサイドプロジェクトで「ちょっとしたアイデアを形にしたい」というときになんかゼロから環境構築するのは面倒だし、かといって適当に作ると後々メンテナンスが大変になる。 以前はViteを使って簡単なプロトタイプを作っていたが最近のAI Codingの進化によりプロトタイプ以上にしっかり動くものまで簡単に作れるようになってきた。そうなるとpure viteより最初からもう少し大袈裟だけども発展性のある技術スタックで作っても良いのではないかと思う。 また、転職して以来Cloudflareを触っていなかったし、最近はNext.jsも触っていなかったので、その辺りのキャッチアップも兼ねて試行錯誤してみることにした。結局RSCに慣れないおじさんなのでPages Ro
We are happy to announce that Biome v2 is officially out! 🍾 Biome v2—codename: Biotype, the first JavaScript and TypeScript linter that provides type-aware linting rules that doesn’t rely on the TypeScript compiler! This means that you can lint your project without necessarily installing the typescript package. With this release, the Core Contributors of the project want to show to the whole comm
TypeScriptの判別可能なユニオン型は、ユニオンに属する各オブジェクトの型を区別するための「しるし」がついた特別なユニオン型です。オブジェクトの型からなるユニオン型を絞り込む際に、分岐ロジックが複雑になる場合は、判別可能なユニオン型を使うとコードの可読性と保守性がよくなります。 通常のユニオン型は絞り込みが複雑になるTypeScriptのユニオン型は自由度が高く、好きな型を組み合わせられます。次のUploadStatusはファイルアップロードの状況を表現したユニオン型です。アップロード中InProgress、アップロード成功Success、アップロード失敗Failureの組み合わせです。
typescript-project-setup-guide.md This is typescript environment setup guide for LLM and humans Baseline Always setup baseline settings pnpm typescript vitest pnpm init --init-type module pnpm add typescript vitest @vitest/coverage-v8 @types/node -D echo "node_modules\ntmp\ncoverage" > .gitignore mkdir -p src # git git init git add . git commit -m "init" package.json { "private": true, "type": "mo
TL;DR: The first stable version Oxlint has been released! With a 50~100x performance improvement over ESLint, support for over 500 ESLint rules, and usage in major companies like Shopify, Airbnb, and Mercedes-Benz, you should give it a try. Get started now. Oxlint is a Rust-powered linter for JavaScript and TypeScript is designed to be fast and simple to adopt. Since its first announcement back in
はじめに 2024年の11月に、札幌で開催された「クラメソさっぽろIT勉強会(仮) #6」という勉強会がありまして、そのライトニングトーク枠に登壇してきました。 タイトルは「minifyの効果を最大限に引き出すTypeScriptコードを書く」です。 昨今のフロントエンド開発では、TypeScriptを使ってコーディングし、それをトランスパイルしてできたJavaScriptファイルのサイズを minify によって削減するのが一般的でしょう。そうしたときに、ふと 「TypeScript の書き方を工夫したら、もっと minify が効率的に効くようになるかも?」 と思いたち、型安全性とコードの読みやすさを壊さない範囲で、どこまでファイルサイズを削れるか挑戦してみた、という話です。 今回はその LT ネタを、改めてブログ記事として共有させて頂きます。 今回のお題: Blazor SplitC
この記事は、下記の記事への反論というよりも、「 TypeScript でバックエンドを書く」というテーマについて、別の観点から整理したい という意図で書いています。 元記事は、文脈が分かりづらいと感じたため、自分なりにバックエンドの特性にフォーカスして再整理しています。 最近、以下の記事を見かけました。 記事の内容は、バックエンドも TypeScript で書きましょうという内容です。 たしかに、TypeScript は現代のフロントエンド開発においてデファクトスタンダードとも言えます。型安全性、補完の効きやすさ、そしてJavaScriptとの互換性。いずれも実務で使うには非常に便利です。フロントエンドではもはや必須とも言える存在です。 ただ、バックエンドという文脈においては、TypeScriptを選ばない理由もあるよね? と感じました。 TypeScript を否定したい訳ではなく、「あ
tskaigi で発表した https://tskaigi.mizchi.workers.dev/ のコピペしやすい用にしたバージョンです。 ほぼ marp のソースコードそのままですが、プロンプトのコピペ用にそのまま公開します。 本資料の内容 うまくいくプロンプト うまくいかないプロンプト、その理由 現状認識 注意: 前日リリースのClaude 4 の評価は間に合ってません!!!! Claude 4 Opus の高すぎる怖い 数時間触った感じ: 改善傾向だが、抱えてる問題も同じ傾向 主張: 言語特化プロンプトが必要(今は) Coding Agent は言語ごとのユースケースに最適化されていない ベストプラクティスをユーザーが取捨選定する必要 TS 周辺は技術選定で発散しがち プログラミング言語間の転移学習は不安定 GitHub を丸暗記しても、コンテキストに応じて翻訳&参照できるかは別の
下のようなツイートを見かけたので少し書いてみます。 おそらくこの方はバックエンドをTypeScriptで書くのは良くないという誰かの意見に反応したものだと思う。そういう意見に惑わされないためにも、宣言しておきます。もうすでにTypeScriptでバックエンドを書いてもいい時代です、と。 っていうか書いてもいいどころか、すでにみんなTypeScriptでバックエンド書いて本番で運用してます。仕事上いろんな会社さんの開発の手伝いとかやってるんですが、全部TypeScriptでバックエンド書いてなくても、バックエンドの一部(BFFなど)をNext.jsやRemixのようなフレームワークを使って書いているところを含めるともう最近は見聞きする相手はみんな本番で運用してます。なのでもうTypeScriptでバックエンド書いてもいいです。 TypeScriptでバックエンド書くということは、多くの場合ラ
This past March we unveiled our efforts to port the TypeScript compiler and toolset to native code. This port has achieved a 10x speed-up on most projects – not just by using a natively-compiled language (Go), but also through using shared memory parallelism and concurrency where we can benefit. Since then, we have made several strides towards running on large complex real-world projects. Today, w
更新履歴 (2025-05-15) ts-morph の API で躓いたポイントの具体例を追記 (2025-05-13) 公開 Codemod とは Codemod(コードモッド)とは、"Code Modification"(コード修正)の略語で、プログラムを使ってコードベース全体にわたる変更やリファクタリングを自動的に行うプロセスや、そのためのツールを指します。 手作業で一つ一つコードを修正する代わりに、スクリプト(codemodスクリプトやトランスフォームと呼ばれる)を実行することで、大規模なコードベースに対しても一貫性のある変更を効率的かつ正確に適用することを目的としています。 主な目的と用途: APIの変更への追従: ライブラリやフレームワークがバージョンアップし、古いAPIが非推奨になったり、使い方が変わったりした場合に、コードベース全体の該当箇所を新しいAPIの呼び出し方に自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く