similarity-ts でAIと人間が書き散らした重複コードを見つける
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に再現させる
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
TypeScriptの条件分岐をスマートに記述するためのTips - Nealle Developer's Blog
はじめに こんにちは、ARCH チームの立川です。 今回が初めてのテックブログになります。 先日、社内で「条件分岐をスマートに評価する」というテーマで、TypeScript（JavaScript）における条件分岐の書き方について発表する機会がありました。古いコードに触れる中で、見通しの悪い記述を多く見かけることがあったため、発表に至った経緯があります。 この記事では、その発表内容をベースにコードの可読性を高める条件分岐のテクニックをご紹介します。基礎的な内容ではありますが、少しでも役立つヒントがあれば幸いです！ 三項演算子をよりスマートに使うためのヒント 三項演算子は非常に便利ですが、状況によってはもっとシンプルで読みやすい代替手段があります。ここでは、等価な三項演算子と比較しながら、それらの方法を紹介します。 null 合体演算子（ ?? ）を活用する null 合体演算子は、左辺が n
Claude Codeを使って自分用のプロトタイプ開発環境を整理した
プロトタイプ開発環境というのは、雑に思いついたwebアプリを素早く作成するための環境のことで1年半くらい前にもこういう記事を書いた。 個人開発やサイドプロジェクトで「ちょっとしたアイデアを形にしたい」というときになんかゼロから環境構築するのは面倒だし、かといって適当に作ると後々メンテナンスが大変になる。 以前はViteを使って簡単なプロトタイプを作っていたが最近のAI Codingの進化によりプロトタイプ以上にしっかり動くものまで簡単に作れるようになってきた。そうなるとpure viteより最初からもう少し大袈裟だけども発展性のある技術スタックで作っても良いのではないかと思う。 また、転職して以来Cloudflareを触っていなかったし、最近はNext.jsも触っていなかったので、その辺りのキャッチアップも兼ねて試行錯誤してみることにした。結局RSCに慣れないおじさんなのでPages Ro
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日から販売していただける予定です。 『型システムのしくみ』について 多くのプログラミング言語では、さまざまな場面で「型」が登場します。特に静的型付き言語では、プログラムを実行せずに潜在的な問題をあぶり出す「型検査」の有用性が広く知られるようになりました。最近では動的型付き言語でも、型ヒントや静的解析ツールとして、この機能を部分的に取り入れる動きがあります。 型検査の背
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node Target Mapping
GitHub - Nergie/no-barrel-file
AI Coding Agents Enablement in TypeScript
