TypeScript/JavaScriptの不要なコードを削除するツール「Knip」の紹介 - ベースマキナ エンジニアブログ
こんにちは、taroです！ 今回は、ベースマキナのTypeScriptのプロジェクトで不要なコードの検知・削除で使用しているKnipについて紹介します。 Knip とは Knipは、TypeScript/JavaScriptのコードベースの不要なコードを検出するCLIツールです。 以下が検出できる不要なコードの例です。 package.jsonのdependencies/devDependenciesの中で使われていないpackage exportされているがどこからもimportされていない変数、関数、型など 使用していないファイル その他、検出できる内容の一覧はこちらで確認できます。 またExperimentalな機能（2024年7月現在）として不要なコードの自動削除も可能です。 ちなみにTypeScript/JavaScriptの不要なコードの検出するツールではts-pruneも知ら
OpenAPI TypeScript
OpenAPI TypeScriptConvert OpenAPI 3.0/3.1 schemas to TypeScript types and create type-safe fetching.
明示的な型注釈によって推論コストを下げるというアプローチ
近年、TypeScript を取り巻くエコシステムでは、ユーザーに明示的な型注釈を求めることで、推論や型生成のコストを下げるというアプローチが注目されています。TypeScript 5.5 beta で 発表された --isolatedDeclarations オプションはその代表的な機能ですし、Deno の提供する新しいパッケージレジストリ JSR が提唱している slow types という考え方も同様のアプローチを求めるものです。 この記事では、上記のようなアプローチが提案された経緯や解決したい課題について、TypeScript を利用するエコシステムの状況も踏まえて整理します。 TypeScript を取り巻くツールチェインと型情報を利用する上でのパフォーマンス 皆さんがご存知の通り、TypeScript の型推論は非常に賢く、その機能は日々アップデートされています。特に以下のよう
TSKaigi 2024で発表した内容の元ネタ「なぜZustand TypeScript実装はこんなに醜いのか」
TSKaigi 2024で短い発表をしましたが、これには元ネタというかオリジナルの記事があります。 ChatGPTに翻訳してもらいました👇 なぜZustand TypeScript実装はこんなに醜いのか ちなみに、JavaScript実装はとてもクリーンです 序論 注: この投稿はZustandライブラリのTypeScript実装に焦点を当てています。 ユーザーコードには影響しませんが、クリーンに保つべきです。 ZustandのJavaScript実装は非常に小さいですが、以下のツイートで見られます。 しかし、そのTypeScript実装はかなり複雑です。 その理由はいくつかありますが、この投稿ではそのうちの一つを探ります。 SetStateInternal型 SetStateInternal 型をもう少し詳しく見てみましょう。 (これは内部使用を意図していることを念頭に置いてください。
ZodでJSONのオブジェクトを実行時に都合の良い型に変換する | フューチャー技術ブログ
いろんなJavaScriptの統計を見ると、今時のウェブフロントエンドの新規開発は80%はTypeScriptになっているということです。また、TypeScript自身を使わなくても、TypeScriptで培われた型推論のパワーで、JavaScriptであってもVSCode上で補完とか思いの外うまくいったりしちゃうので、TypeScriptフレンドリーというのはますます重要になっています。 ですが、TypeScriptが有効なのはコンパイル前とか実装中であり、実行時に流れてくるJSONが果たしてきちんとした型通りの定義なのかはTypeScriptの範疇外です。そこでZodとかのバリデーションを行ってくれるライブラリが使われます。Zodを使えばJSONが規定通りの構造をしているか確認した上で、TypeScriptの型を持った変数に安全に代入してくれます。 ですが、JSONというのはネットワー
TypeScriptのパフォーマンス改善
2024/05/11に行われたTSKaigiで発表したLTの資料です！ ◎概要 TypeScriptはJavaScriptのスーパーセットとして、静的型付けと高度な型システムを提供し、大規模なプロジェクトの開発を助けています。しかし、これらの利点を最大限に活用するためには、コンパイルパフォーマンスの最適化が不可欠です。コンパイル速度を上げることでビルド時間やテスト実行時間の削減を行うことができます。今回の発表では、TypeScriptのコンパイルパフォーマンスを改善するための具体的な手法とその背後にある理論をいくつか紹介します。 ◎内容 1. TypeScriptのパフォーマンスとは何か、そしてなぜそれが重要なのか 2. コンパイル速度を改善するための具体的な手法とその背後にある理論 本資料で紹介している内容については以下の記事で詳しく記載していますので合わせて参照していただければと思いま
TypeScriptとGraphQLで実現する型安全なAPI実装
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信（今回はこれをAPIと呼びます[1]）などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
JSR Meetup に参加してきた
JSR Meetup JSR が気になっていたことや、Deno の中の人が主催というのも良いなと思って、ささっと参加してきました。自分用に雑にまとめておきます。 https://jsr.io/ https://github.com/jsr-io/jsr ハッシュタグ 自分のメモ Deno Land Inc. が開発、運用しているパッケージレジストリ プライベートは今のところ予定されていない TypeScript をそのまま登録できる ESM 対応 OSS で開発されている 自前の JSR を立てることもできる 積極的に改善されていきそう ドキュメントが生成される Web UI がモダン Deno が流行らないと苦しそう @std を Deno が持ってるのは他からはちょっとな ... って思われそう キレイな npm 雑感 印象としては使ってみても良さそうという感じです。ただ無理に npm
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
エラーや非同期処理をより安全に扱うための TypeScript ライブラリ Effect-TS
TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性（concurrency）：Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ（composability）：小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理（resource-safety）：処理が失敗したとしても、安全にリソースを開放する 型安全性（type-safety）：TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理（error handling）：構造化された信頼性の高い方法でエラーを処理する 非同期性（asynchronicity
Next.js 型安全なルーティングを使う
Next.js 型安全なルーティングを使う 2024.04.28 Next.js では実験的な機能として、型安全なルーティングを利用できます。この機能を使うことでリンク先のパス名を静的に検査できるため、typo などのエラーを事前に防ぐことができます。 この記事における「型安全」とは、静的な型検査によりランタイムで起こり得るエラーを事前に検知することを指します。 Next.js では Next.js 13.2 より実験的な機能として、型安全なルーティングを利用できます。この機能を使うことでリンク先のパス名を静的に検査できるため、typo などのエラーを事前に防ぐことができます。 なお、型安全なルーティングを利用するためには App Router と TypeScript を使用している必要があります。 型安全なルーティングの利用方法 型安全なルーティングを有効にするためには、experim
Node.js + TypeScriptのモジュールを整理してみる
はじめにlink 最近受けるNode.js + TypeScript環境の相談の中で、CommonJSやECMAScript Modulesのあたりで落とし穴にはまっている人が多いという事に気づいた。 Node.jsは歴史的にCommonJSとECMAScript Modules（以後ESMと表記）がどうしても入り乱れる環境にあり、これにTypeScriptのモジュールが加わると組み合わせでさらに複雑度が増すのが現状である。 説明する際に口頭より整理した文章が欲しいと思ったので記事にする。 以下のリポジトリで検証コードを管理している。 https://github.com/koh110/module_test Node.jsモジュールチェックシートlink まず最初にNode.jsにおけるCommonJSとESMの挙動について整理する。 いきなり書かれても把握できないかもしれないが、一旦こ
ESLintのFlat Config移行でやって良かったこと
ESLintのv9.0.0ではFlat Config(eslint.config.js)がデフォルトになりました。これまでの.eslintrcの形式のファイルも使えますが、ESLINT_USE_FLAT_CONFIG環境変数を設定する必要があるようです。 これを機にFlat Configで普段使っているルールを整理して書いてみることにしました。その際やって良かったことをまとめます。 作成した設定はSharable Configとして公開しています。 typescript-eslintのtseslint.configを使う Flat configはこのように配列で書きます。 export default [ { rules: { "no-unused-vars": "error", "no-undef": "error" } } ]; // @ts-check import eslint f
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - marpple/FxTS: A functional programming library for TypeScript/JavaScript
GitHub - cellajs/cella: TypeScript template to build local-first SaaS with hono + pg + drizzle + electric-sql + react + shadcn.
Prismaでスキーマ変更を行う際のベストプラクティス
Real World Type Puzzle and Code Generation
tRPCを実務に導入して分かった旨味と苦味
Prisma ORMを2年運用して培ったノウハウを共有する
TypeScript 関数型スタイルでバックエンド開発のリアル
