Biome v2—codename: Biotype
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
判別可能なユニオン型 (discriminated union) | TypeScript入門『サバイバルTypeScript』
TypeScriptの判別可能なユニオン型は、ユニオンに属する各オブジェクトの型を区別するための「しるし」がついた特別なユニオン型です。オブジェクトの型からなるユニオン型を絞り込む際に、分岐ロジックが複雑になる場合は、判別可能なユニオン型を使うとコードの可読性と保守性がよくなります。 通常のユニオン型は絞り込みが複雑になるTypeScriptのユニオン型は自由度が高く、好きな型を組み合わせられます。次のUploadStatusはファイルアップロードの状況を表現したユニオン型です。アップロード中InProgress、アップロード成功Success、アップロード失敗Failureの組み合わせです。
typescript-project-setup-guide.md
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
Announcing Oxlint 1.0
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
minify の効果を最大限に引き出す TypeScript コードを書く
はじめに 2024年の11月に、札幌で開催された「クラメソさっぽろIT勉強会(仮) #6」という勉強会がありまして、そのライトニングトーク枠に登壇してきました。 タイトルは「minifyの効果を最大限に引き出すTypeScriptコードを書く」です。 昨今のフロントエンド開発では、TypeScriptを使ってコーディングし、それをトランスパイルしてできたJavaScriptファイルのサイズを minify によって削減するのが一般的でしょう。そうしたときに、ふと 「TypeScript の書き方を工夫したら、もっと minify が効率的に効くようになるかも?」 と思いたち、型安全性とコードの読みやすさを壊さない範囲で、どこまでファイルサイズを削れるか挑戦してみた、という話です。 今回はその LT ネタを、改めてブログ記事として共有させて頂きます。 今回のお題: Blazor SplitC
TypeScriptをバックエンドで使わない理由
この記事は、下記の記事への反論というよりも、「 TypeScript でバックエンドを書く」というテーマについて、別の観点から整理したい という意図で書いています。 元記事は、文脈が分かりづらいと感じたため、自分なりにバックエンドの特性にフォーカスして再整理しています。 最近、以下の記事を見かけました。 記事の内容は、バックエンドも TypeScript で書きましょうという内容です。 たしかに、TypeScript は現代のフロントエンド開発においてデファクトスタンダードとも言えます。型安全性、補完の効きやすさ、そしてJavaScriptとの互換性。いずれも実務で使うには非常に便利です。フロントエンドではもはや必須とも言える存在です。 ただ、バックエンドという文脈においては、TypeScriptを選ばない理由もあるよね？ と感じました。 TypeScript を否定したい訳ではなく、「あ
TS特化Clineプログラミング(テキスト版)
tskaigi で発表した https://tskaigi.mizchi.workers.dev/ のコピペしやすい用にしたバージョンです。 ほぼ marp のソースコードそのままですが、プロンプトのコピペ用にそのまま公開します。 本資料の内容 うまくいくプロンプト うまくいかないプロンプト、その理由 現状認識 注意: 前日リリースのClaude 4 の評価は間に合ってません!!!! Claude 4 Opus の高すぎる怖い 数時間触った感じ: 改善傾向だが、抱えてる問題も同じ傾向 主張: 言語特化プロンプトが必要(今は) Coding Agent は言語ごとのユースケースに最適化されていない ベストプラクティスをユーザーが取捨選定する必要 TS 周辺は技術選定で発散しがち プログラミング言語間の転移学習は不安定 GitHub を丸暗記しても、コンテキストに応じて翻訳&参照できるかは別の
TypeScriptでバックエンドを書いてもいい時代です
下のようなツイートを見かけたので少し書いてみます。 おそらくこの方はバックエンドをTypeScriptで書くのは良くないという誰かの意見に反応したものだと思う。そういう意見に惑わされないためにも、宣言しておきます。もうすでにTypeScriptでバックエンドを書いてもいい時代です、と。 っていうか書いてもいいどころか、すでにみんなTypeScriptでバックエンド書いて本番で運用してます。仕事上いろんな会社さんの開発の手伝いとかやってるんですが、全部TypeScriptでバックエンド書いてなくても、バックエンドの一部(BFFなど)をNext.jsやRemixのようなフレームワークを使って書いているところを含めるともう最近は見聞きする相手はみんな本番で運用してます。なのでもうTypeScriptでバックエンド書いてもいいです。 TypeScriptでバックエンド書くということは、多くの場合ラ
Announcing TypeScript Native Previews - 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
TypeScript の codemod ツール開発時の失敗談と得た知見メモ
更新履歴 (2025-05-15) ts-morph の API で躓いたポイントの具体例を追記 (2025-05-13) 公開 Codemod とは Codemod（コードモッド）とは、"Code Modification"（コード修正）の略語で、プログラムを使ってコードベース全体にわたる変更やリファクタリングを自動的に行うプロセスや、そのためのツールを指します。 手作業で一つ一つコードを修正する代わりに、スクリプト（codemodスクリプトやトランスフォームと呼ばれる）を実行することで、大規模なコードベースに対しても一貫性のある変更を効率的かつ正確に適用することを目的としています。 主な目的と用途: APIの変更への追従: ライブラリやフレームワークがバージョンアップし、古いAPIが非推奨になったり、使い方が変わったりした場合に、コードベース全体の該当箇所を新しいAPIの呼び出し方に自
チープリサーチ：Mastra で Deep Research の模倣し、Open Cheap Research を作りました。
こんにちは、オートロ株式会社で代表をしております。福田です。今回も、オープン開発チームで試した内容を共有したいと思います。 今回は、日本でも大人気になっている TypeScript で AI エージェント開発ができる、Mastra を使ってディープリサーチの模倣品の Open Cheap Research を開発した話をします。 ソースコードは、こちらで公開しております。 Mastra とは Mastra は、AI エージェントを開発するためのフレームワークです。ほとんどの AI エージェント開発フレームワークが、Python で公開されているのに対して、Mastra は、TypeScript で、開発することができるため、ウェブエンジニアが AI エージェント開発に参戦するために非常に有効なツールになっています。 引用元：公式サイト Mastra でできること Mastra で、できるこ
ESLint コアルールの TypeScript 対応について
ESLint コアルールの TypeScript 対応について ESLint v9.23.0 で ESLint のコアルールの TypeScript 対応が開始しました。 その後の ESLint のアップデートでもコアルールの TS 対応が進んでいます。ESLint コアの責務を増やすような機能追加は少し意外だと感じたので、その背景について調べてみました。 背景: 従来のコアルールの拡張方法の課題 ESLint のコアルールは JavaScript を想定して書かれたものであるが、TypeScript に対してもほぼ期待通り動作するルールが多い。TypeScript は JS のほぼ上位互換な言語であるため、TypeScript 用のパーサー (@typescript-eslint/parser) が吐き出す AST もほぼ上位互換であり、パーサーさえ TS 用のものを使えば多くの ESL
新刊『型システムのしくみ』の発売を4/18に予定しています
ご来店ありがとうございます。新刊発売予定のお知らせです。 2025年4月18日（金）、遠藤侑介著『型システムのしくみ ― TypeScriptで実装しながら学ぶ型とプログラミング言語』の発売を予定しています。なお、2025年4月16日（水）から開催されるRubyKaigi 2025会場のBOOKSTOREにて、著者サイン会に合わせた先行発売を予定しています（紙書籍のみ。部数には限りがあります）。ジュンク堂池袋本店様でも4月16日から販売していただける予定です。 『型システムのしくみ』について 多くのプログラミング言語では、さまざまな場面で「型」が登場します。特に静的型付き言語では、プログラムを実行せずに潜在的な問題をあぶり出す「型検査」の有用性が広く知られるようになりました。最近では動的型付き言語でも、型ヒントや静的解析ツールとして、この機能を部分的に取り入れる動きがあります。 型検査の背
tsconfig.json paths やめ方
tsconfig.jsonのpaths設定でimport文にエイリアスを使えるようにしたものの、 tscでトランスパイルするとエイリアス形式のパスは変換されない パスの変換のためにtsconfig-pathsなどの追加ライブラリが必要で、ビルドコマンドが冗長になる jestなどはpathsを反映するために追加設定が必要 などで微妙な気持ちになってきたことはありませんか。 一度導入すると利用箇所が結構多くなってきて手動で戻すには大変すぎるし、まあ動いてるからいいか...みたいな。 そんな時のために自動で相対パスに戻せるeslintプラグインを作ってみました。 やめ方 @mkizka/eslint-plugin-relative-import を入れてeslint --fixするだけ。 設定は↓のような感じです。 // eslint.config.js import { relativeImp
TypeScript の Go 移植に備えて知っておくべきこと
はじめに こんにちは、ダイニーの ogino です。 TypeScript のコンパイラは今まで TypeScript で実装（セルフホスト）されていました。 それが TypeScript 7.0 から、Go による実装に移植され、10 倍高速になります。 本記事は、移植に関して筆者が疑問に感じた点を、GitHub discussion や TypeScript lead architect のインタビュー動画などから調べてまとめたものです。 移行の背景 今回 Go に移植される背景は、大規模な TypeScript コードベースをコンパイルする際のスピードの遅さにあります。 例えば VSCode のコードベース (150 万行) に対して tsc を実行すると、約 80 秒もかかります。 TypeScript のコンパイルは大きく以下の段階に分けられ、その内の check が特に複雑で重
4 ステップでモダンな tsconfig.json を作る - mizdra's blog
tsconfig.json を使うと、型チェックを緩く/強くしたり、また出力する JS の形式を変えたりできる。しかしいくつかの事情から、正しく書くのが難しい。 オプションの数が非常に多い その数なんと 133 個 *1 オプションの意味や役割が理解しにくい 公式ドキュメントは丁寧にかかれているが... JavaScript や TypeScript の仕様、型の知識、歴史的経緯などを知らないと理解しづらい 推奨されるオプションが変わっていく 言語やエコシステムの進化/変化によって変わる 最近だと Node.js の TypeScript サポートで変わった 「オプションの細かい意味とかは一旦いいから、モダンで最小限の tsconfig.json がすぐに欲しい！！！」。そうした声に応えて、id:mizdra がオススメする「4 ステップでモダンな tsconfig.json を作る方法」
「どう扱うか」で設計するエラーハンドリング / noren_ts #1
https://dinii.connpass.com/event/348179/
neverthrowと比較したoption-tについて - saneyuki_s log
たまたまoption-tを紹介してくれるブログ記事があったみたいで、その上でneverthrowの方がおすすめみたいな感じのtweetを見かけて、色々言いたいことがあったので久々に書いてみる。 https://t.co/GJGyxeyoZM fp-ts を入れるのを躊躇う環境で Result 型とコンビネータが欲しい場合の私のおすすめは neverthrow です— naoya (@naoya_ito) 2023年1月19日 ・ResultAsync という async に対応している ・fromPromise / fromThrowable を使えば Result の入れ子が嫌なときに async/await や例外を使った普通の手続きで書いて、fromPromise/Throwable で包むという回避手段が取れる— naoya (@naoya_ito) 2023年1月19日 ・Res
GitHub - typedgrammar/typed-japanese: 🌸 Learn Japanese grammar with TypeScript
If you can write TypeScript, you can understand Japanese! Typed Japanese is a TypeScript type-level library that enables the expression of complete Japanese sentences through the type system. It creates a domain-specific language (DSL) based on Japanese grammar rules, allowing a subset of grammatically correct natural language to be written and verified using TypeScript's compiler. This project al
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AI Coding Agent Enablement in TypeScript
