Valibot作者が開発したフォームライブラリ Formisch を使ってみる - プププなテクブ
フロントエンド開発でフォームを実装するとき、こんな経験はないでしょうか。 バリデーションロジックがコンポーネントとごっちゃになって見通しが悪い React Hook Form や Formik を使っているが、バンドルサイズが気になる フレームワークを乗り換えたとき、フォームライブラリも全部書き直しになった こうした課題を整理していたところ、辿り着いたのが Formisch です。TypeScript 向けスキーマバリデーションライブラリとして有名な Valibot と同じ作者のFabianが手がけています。 今回はこのFormischを使ってみたいと思います。今回のサンプルコードは以下にあります。 github.com Formisch とは Formisch はこれらの問題を解決するために設計された、モジュラーかつ型安全なフォームライブラリです。React / SolidJS / Vu
Hono × Inertia.js が作る新しい型貫通体験に触れてみた
// サーバー側（Hono） app.get('/posts/:id', (c) => { const post = findPost(c.req.param('id')) return c.render('Posts/Show', { post }) }) // クライアント側（React） export default function Show({ post }: PageProps<'Posts/Show'>) { return <h1>{post.title}</h1> } post の型は Post として完全に推論される。間に API 定義も DTO も tRPC もスキーマ生成もない。サーバーで c.render() の第2引数に渡したオブジェクトが、そのまま React の props として、しかも完全に型付きで届く。 「API なし SPA」を謳う Inertia.j
Perry — TypeScript → Native
v0.5.306 — generational GC + lazy JSON tape default, faster than Node and Bun on most benchmarks One Codebase. Every Platform. Native Performance.Perry compiles TypeScript to native GUI and CLI apps on macOS, iPadOS, iOS, Android, Linux, Windows, watchOS, tvOS, WebAssembly, and the Web. No runtime. No Electron. Just native binaries.
2026年版：JavaScript/TypeScriptのロギング入門
本番環境で障害が発生したとき、手がかりになるのは結局ログだけだった——という経験は、多くのエンジニアが持っているのではないでしょうか。ところが、開発中に書き散らしたconsole.logは肝心なときに役に立たないことが多いものです。「ここ通った」「動いた」といったメッセージや、巨大なオブジェクトがそのまま出力されているだけでは、原因特定は困難です。 かといって、本格的なロギングライブラリを導入するのは大げさに感じることもあります。winstonやPinoは高機能ですが、設定項目が多く、エッジ環境では動かなかったり、依存関係が増えたりと、ちょっとしたAPIサーバーには重たい選択肢かもしれません。 本記事では、console.logの限界を整理した上で、実用的なロギング環境の構築方法を紹介します。サンプルコードにはLogTapeを使います。依存ゼロで軽量、Node.js・Deno・Bun・エッ
TUI を構築するための Typescript ライブラリ OpenTUI
AI コーディングエージェントの普及により、ターミナルベースの TUI アプリケーションの需要が高まっています。OpenTUI は Typescript で TUI アプリケーションを簡単に構築できるライブラリです。この記事では OpenTUI の特徴と基本的な使い方を紹介します。 AI コーディングエージェントの普及により、ターミナルにふれる時間が増えた開発者が多いでしょう。そんな中、ターミナルベースの TUI (Text-based User Interface) アプリケーションの需要が高まっています。OpenTUI は Typescript で TUI アプリケーションを簡単に構築できるライブラリです。OpenTUI は opencode の基盤として利用されていることもあり、今後も開発が活発に続けられることが期待されます。この記事では OpenTUI の特徴と基本的な使い方を紹介
TypeScriptのTips - カリー化で業務ルールと処理を分離する
自分がコーディングで使っている、ちょっとしたテクニックを紹介します。 今回のテーマは カリー化 です。 このテクニックを使うことで、業務ルールと処理を分断し再利用性・テスト容易性が向上します。 サンプルとして、手数料を計算する処理を題材にします。 要件は以下の通りとします。 関数は金額を受け取り、適応する手数料を返す 手数料は価格帯によって決定する 0 ~ 499円は手数料 300円 500 ~ 1999円は手数料 50円 2000円以上は手数料なし 場合によっては手数料が複数かかる場合もある よくある実装例 まずは、よくある実装例です。 （そもそもハードコードがよくない、などは目を瞑ってほしい。） type FeeRule = { min: number; max: number | null; fee: number; }; const calculateFee = (amount:
2025年に使い始めて良かったツール10選 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2025年に使い始めて良かったツール10選 2025年に個人的に使い始めて、開発体験が向上したと感じたツールを紹介します。 Claude Code これを言っておかないと嘘になるので、まず紹介します。 ご存知の通り、AIコーディングエージェントの覇権ツールで以下の特徴を備えています。 コーディングにおいて最高峰のモデル（執筆時点ではOpus 4.5）がサブスク範囲で使用できる サブエージェントやエージェントスキルといったコーディングのクオリティを限界まで上げるための機能をいち早く取り入れている 前者は特に重要で、基本的に従量課金だったC
oxlint, oxfmt, tsgoを導入して開発環境が爆速になった
はじめに こんにちは。ぷーじ（@yug1224）です。 Dress Code Advent Calendar 2025 24日目の記事です🎄 フロントエンド・バックエンド開発において、リンター、フォーマッター、型チェッカーはコード品質を担保する上で欠かせないツールですよね。しかし、プロジェクトの規模が大きくなるにつれ、これらのツールの実行時間がCI/CDのボトルネックになることがあります。 私たちのプロジェクトはTypeScriptファイルだけで1万ファイル以上という規模であり、まさにこの問題に直面していました。 今回、Rust製の高速ツールチェーンであるoxc（Oxidation Compiler） と、TypeScript公式のTypeScript Native Preview（tsgo） を導入することで、CI時間を大幅に削減しました！ この記事では、導入の背景、実際の改善結果、そ
Cap'n Webについて
Cap'n Webが面白いのでその紹介です。 Cap'n Web概要 Cap'n WebはJavaScriptネイティブなRPCの実装でcapnwebというnpmライブラリが提供されています。作者がCloudflare Workersを作ったKentonなんで注目しています。実際レポジトリもCloudflareのorgにあります。 また、Cloudflareのブログで紹介されています。こちらを見ればだいたいわかります。 Cap'n Webの特徴は以下です。 サーバーとブラウザで動作する JavaScriptのメソッド呼び出し、オブジェクト操作をそのままにRPC呼び出しができる HTTP、WebSocket、postMessage()で動作する メジャーなブラウザ、Cloudflare Workers、Deno、Node.jsをサポート（後述するHono AdapterだとBunもサポート）
「とりあえずNext.js」をやめてBetter-T-Stackを試してみた
株式会社アップルワールドのrikuです。 ※この記事はアップルワールド Advent Calendar 2025の9日目の記事です。 はじめに 2025年12月3日に起きたNext.jsおよびRSCのセキュリティ問題を受けて、弊社のフロントエンド技術選定について真剣に考える必要が出てきました。 今回の問題については各所で再三触れられているため、ここでは詳細を割愛します。 弊社では今まで利用者数が多いこと、AIによる開発と親和性が高いことを理由に2025年は「とりあえずNext.js」にすることが多かったのですが、弊社の規模・状況だと万が一問題が発生した際に会社存続のリスクに繋がる可能性があるので、2026年は並行して別の選択肢も試したいと考えました。 現在使用されているライブラリ・フレームワーク 私の知る限り、弊社のJavaScript/TypeScriptを利用した開発には主に以下のライ
Prismaしか知らない私が、DrizzleというORMについて調べてみたぜ
本記事のサマリ Prismaを使ってきた私が、最近注目されているDrizzle ORMについて調べてみました。型の扱いやマイグレーション周り、そして機能面でPrismaとどう違うのかを実際のドキュメントや比較記事を元に整理しています。SQLに近い記述ができる点や軽量性は魅力的でしたが、Prismaの安定感とも比較してどちらを選ぶか悩ましいところです。 なぜDrizzleを調べることになったのか 普段の開発では、Next.jsアプリでPrismaを使っています。schema.prismaファイルにモデル定義を書いて、prisma migrate devでマイグレーションを生成し、生成されたクライアントで型安全にクエリを書く。この流れがとても気に入っていて、特にマイグレーションの安心感は抜群ですよね。チームで開発していてもデータベーススキーマの管理で困ることはほとんどありません。 そんな中で、
never が好き - Object.create(null)
この記事は はてなエンジニア Advent Calendar 2025 の 4 日目の記事です. id:susisu です. TypeScript の never 型がたいへん奥ゆかしいので見ていってください. 基礎編 まずは never 型がどういったものなのかを見てみましょう. 値のない型として 例えば number 型に対しては 42, 3.14, NaN など , string 型に対しては "", "Hello" などのように, 一般的な型にはその型が付けられる値が存在します. 一方で never 型にはそういった値が存在しません (こういった型は一般にボトム型などと呼ばれたりします). never 型の変数には何を代入しようとしてもエラーになります. const x: never = 42; // エラー undefined や null も「値が存在しない」と説明されることが
Type-safe Composable CSS
From simple UI styles to full Design Systems, write code using Styleframe’s powerful TypeScript CSS API. import { styleframe } from 'styleframe'; import { useColorDesignTokens } from '@styleframe/theme'; const s = styleframe(); const { variable, ref, selector } = s; const spacing = variable('spacing', '1rem'); const { colorPrimary } = useColorDesignTokens(s, { primary: '#318fa0', }); selector('.bu
TypeScript 6.0で非推奨化されるオプションたち
2025-11-23 TSKaigi Hokuriku 2025
私がTypeScriptで `interface` よりも `type` を好む理由
テックリード @ 株式会社カケハシ 医療SaaSの共通基盤を開発。TypeScriptと関数型プログラミングで堅牢なシステム設計を実践。 はじめに TypeScriptで型を定義する際、interface と type のどちらを使うべきか。これは、多くの開発現場で一度は議論になるテーマではないかと思います。 世の中の多くのドキュメントや記事では、クラスへの implements のしやすさや、interface が持つ「宣言のマージ（Declaration Merging）」の利便性が紹介されることもあり、interface の利用が推奨されるケースもよく見かけます。 しかし、特にサーバサイドアプリケーションや、ある程度規模のあるシステムを開発する上で、私はこの「宣言のマージ」機能が、時として予期せぬ挙動や、場合によってはセキュリティ上のリスクを静かにもたらす要因になると感じています。
Hono CLI 爆誕
これまでHonoは数々の新しいことを提供してきました。正規表現を活かしたルーター、サーバーサイドの軽量JSX、TypeScriptの型によるRPC、Web Standardを使ったマルチランタイム対応などなど。アイデアと実装力で世界と戦って来たわけです。 本日私達が紹介するのは「Hono CLI」です。 Hono CLIは全く新しいコンセプトのコマンドラインインターフェースです。 create-* ではありません ただの開発用（dev&build&deploy）のコマンドではありません Viteのラッパーではありません 人間とAIのためのCLIです。インストールすると のようにhonoコマンドを使うことができます。5つのサブコマンドがあります。 hono docs hono search hono request hono serve hono optimize では一つ一つを見ていきまし
【結論】TypeScriptの型定義はtypeよりinterfaceを使うべき理由
はじめに TypeScriptでコンポーネントのPropsやオブジェクトの型を定義するとき、typeとinterfaceのどちらを使うべきか、一度は悩んだことがあるのではないでしょうか。 巷では「どちらでも良い」「チームで統一されていればOK」といった意見もよく見かけます。 しかし、私は 明確な理由をもって「基本的にはinterfaceを使うべき」 だと主張します。 この記事では私の実体験で遭遇したReactのPropsの深刻なパフォーマンス問題を例に交えながら、なぜinterfaceが優れているのか、そしてtypeはどのような場面で使うべきなのかを解説します。 type aliasを使いたくなる魅力と、その裏に潜む罠 まず、なぜ多くの開発者がtypeを選びがちなのでしょうか。 それは、開発体験の良さにあります。 typeで定義した型は、VSCodeなどのエディタでホバーすると、最終的に解
【TypeScript】カスタムエラーのすすめ
TypeScriptで開発をしていると、APIエラーやバリデーションエラーなど、さまざまなエラーを扱う場面があります。 そんなときに、標準のErrorクラスだけで対応していませんか。 この記事では、カスタムエラーを導入するメリットと、ボイラープレートを減らしてカスタムエラーを楽に定義出来るライブラリを紹介します。 カスタムエラーを作る理由 標準のErrorクラスを使用することで楽にエラーを作成できますが、次のような問題があります。 エラーの種類を区別しづらい 追加の情報（HTTPステータスやエラーコードなど）を持たせづらい メッセージが一貫しない たとえば次のような例を考えてみましょう。 try { throw new Error('User not found'); } catch (error) { if (error.message.includes('not found')) {
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドにおける「型」の責任分解に対する1つのアプローチ
Building AI Agents with TypeScript #TSKaigiHokuriku
