Modern Node.js Patterns for 2025
Node.js has undergone a remarkable transformation since its early days. If you’ve been writing Node.js for several years, you’ve likely witnessed this evolution firsthand—from the callback-heavy, CommonJS-dominated landscape to today’s clean, standards-based development experience. The changes aren’t just cosmetic; they represent a fundamental shift in how we approach server-side JavaScript develo
「TypeScriptが当たり前」になった世界において、ESモジュール本来の運用に必要な考え方と設定とは
「TypeScriptが当たり前」になった世界において、ESモジュール本来の運用に必要な考え方と設定とは こんにちは、藤吾郎（gfx）と申します。Starleyという会社でおしゃべりAIアプリ「Cotomo」を開発しています。TypeScript歴は10年くらいです。 はじめに - TypeScriptが当たり前になった世界今年（2025年）はTypeScriptがリリースされて13年、ESモジュールが導入されたES2015のリリースから10年が経ちます。今やJavaScriptプロジェクトにおいては、TypeScriptが当たり前の世界になってきました。つまり「JavaScriptプロジェクトの実装言語のデフォルトはTypeScript」という状況にかなり近づいています。 TypeScriptが当たり前の世界とは、JavaScript処理系がデフォルトでTypeScriptをサポートして
4 ステップでモダンな tsconfig.json を作る - mizdra's blog
tsconfig.json を使うと、型チェックを緩く/強くしたり、また出力する JS の形式を変えたりできる。しかしいくつかの事情から、正しく書くのが難しい。 オプションの数が非常に多い その数なんと 133 個 *1 オプションの意味や役割が理解しにくい 公式ドキュメントは丁寧にかかれているが... JavaScript や TypeScript の仕様、型の知識、歴史的経緯などを知らないと理解しづらい 推奨されるオプションが変わっていく 言語やエコシステムの進化/変化によって変わる 最近だと Node.js の TypeScript サポートで変わった 「オプションの細かい意味とかは一旦いいから、モダンで最小限の tsconfig.json がすぐに欲しい！！！」。そうした声に応えて、id:mizdra がオススメする「4 ステップでモダンな tsconfig.json を作る方法」
A 10x Faster TypeScript - TypeScript
While we’re not yet feature-complete, these numbers are representative of the order of magnitude performance improvement you’ll see checking most codebases. We’re incredibly excited about the opportunities that this massive speed boost creates. Features that once seemed out of reach are now within grasp. This native port will be able to provide instant, comprehensive error listings across an entir
React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
SimpleWebAuthn
SimpleWebAuthnA collection of TypeScript-first libraries for simpler WebAuthn integration. Supports modern browsers and Node. Simple to UseIt's in the title! SimpleWebAuthn makes it as easy as possible to add WebAuthn-powered passkeys to your websites so that you can move on to the fun stuff. First-Class TypeScript SupportEverything is authored in 100% TypeScript! And a dedicated package for type
【Chrome】いちど拒否した位置情報やカメラの権限を何度も何度も何度も何度も何度も何度も何度も何度も要求できるようになる - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 現在のブラウザは、いちどカメラやPUSH通知の権限要求を拒否すると、その後要求プロンプトを出すことができません。 Webサイトができることは、『〇〇を許可してください』とウィンドウを出すことくらいです。 ↓人類史上最悪の許可要求ウィンドウの例 この後設定欄から各機能を有効化するためには、ユーザによる絶対的能動的な操作が必要となります。 また、プライバシーとセキュリティ設定から許可しない設定をしておくと、たったの一度すらもチャンスが与えられず、一生権限を要求することはできません。 結果としてPUSH通知の権限要求などは、9割以上のユーザが
TypeScript 5.8のerasableSyntaxOnlyフラグ。enumやnamespaceが消える日が来た
TypeScript 5.8で導入されるerasableSyntaxOnlyフラグを使うと、enumやnamespace、クラスのパラメータプロパティ、moduleキーワードなどの構文をエラーとして検出できます。これらの構文はNode.jsでTypeScriptを実行する際に非互換な構文であり、本フラグの導入によりNode.jsとTypeScriptの互換性が高まります。 本記事では、erasableSyntaxOnlyフラグの挙動と、なぜこのフラグが導入されたのかを解説します。 erasableSyntaxOnlyフラグの挙動 erasableSyntaxOnly とは、「削除可能な構文のみ」という意味です。削除可能な構文とは、Node.jsでTypeScriptを実行される際に削除される構文のことです。後ほど詳しく解説します。 erasableSyntaxOnlyフラグは、tsconf
Testing JavaScript をやってみたら学びがあって良かった話 - Adwaysエンジニアブログ
こんにちは。リファクタリングが大好きなフロントエンドおじさん梅津です。 自信を持ってリファクタリングするには信頼できる自動テストが必要ですよね。 じゃあ信頼できる自動テストとはなんだろう？どう書いたらいいんだろう？と考えていました。 とくにコンポーネントを含む UI テストに対しての悩みが強かったです。 そんなときに出会ったのが Testing JavaScript です。 この記事ではその Testing JavaScript の紹介をしたいと思います。 Testing JavaScript とは Testing JavaScript は PayPal のエンジニアである Kent C. Dodds によって作成された教材です。 ページを開いてすぐ目に飛び込んでくるテスティングトロフィーが特徴的ですね。 Testing JavaScript では、ここに記されている Static, Un
リーダブルなテストのための、jest モックファクトリー関数
単体テストを書く時、モジュール間の関連を検証するため、一部のモジュールをモックする必要が出てくることがあります。モックは様々な手法がありますが、書き方によって、メンテナンス性やテストの可読性が変わります。一般的に行われるモック手法を確認しつつ、よりリーダブルなテストを書く方法を紹介します。 ログイン API を呼び出す Web API クライアント 今回紹介する、モック対象の Web API クライアントです。Native Fetch API を関数でラップした、自作の Web API クライアント（ログインするためのlogin関数）です。 export type Data = { redirectUrl: string; }; export type Input = { email: string; password: string; }; export async function l
Jestでプライベートメソッドをテストする - skysan's 雑記帳
はじめに メソッド内部で呼ばれる別の(プライベート)メソッドの値をテストする。 テストのフレームワークはJestを利用する。 環境 pnpm: 8.10.5 typescript: 5.2.2 jest: 29.7.0 ts-jest: 29.1.1 実装クラス export class SampleClass { constructor(private _text: string) {} public exec(): void { const msg = this.privateMethod(this._text) // do somthing } private privateMethod(text: string) { return 'hello! ' + text } } テストコード test('private method test', () => { const testCl
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
Blobとは何か理解していない方へ
はじめに 昨日ファイルを扱う実装をしている際、github copilotが以下のサジェストをしました const config = { headers: { "content-type": "multipart/form-data" }, responseType: "blob", }; try { const res = await this.axios.post( "/api/export_file", formData, config ); const url = window.URL.createObjectURL(new Blob([res.data])); このサジェストは、バイナリデータを扱う際のJavaScriptの機能を活用するものでした。せっかくCopilotが提案してくれたのに、これらが何を機能するものなのか、その詳細を理解していなかったため、ここでそれらについて調
docker-composeとlocalstackを使ってローカルでAWS SDK for JavaScript V3を動かしてみる | DevelopersIO
docker-composeとlocalstackを使ってローカルでAWS SDK for JavaScript V3を動かしてみる AWS SDK for JavaScriptのV3の存在を最近知りました。この「AWS SDK for JavaScript V3」を localstackを使いローカルで試せる環境を作ってみました(※AWS SDKから呼び出せる機能はlocalstackがカバーしているものに限られます)。 以下、docker-composeとlocalstackを使い、ローカルでAWS SDK for JavaScript V3を動かすサンプルプログラムとなります。AWS SDKを呼びだすプログラムはTypeScriptとし ts-node で実行してみました。 動作環境の作成 予めdocker-composeはローカルPCにインストールしておく必要があります。今回はMa
HonoでAPI付き雑React SPA最小
laisoさんが書いてたのほぼなんだけど Honoは文字列でもStreamでもなんでも返せるからサーバーサイドもReactで書けるし、tsconfig.jsonで適切に設定すればJSXなんでもいけるし、Viteのdev-serverがあるから、サーバーもクライントも同時に開発、ビルドできて、もちろんAPIを生やすのが得意で、雑React SPA環境（API付き！）作るのに向いてるよ。 作り方解説します。めんどい人はここにプロジェクト作ってるからclone、ダウンロードしてください。 まず、create-honoして、cloudflare-pagesのテンプレートを選ぶ。bunをパッケージマネージャーに使ってる。
HonoでAPIだけ作って素のReact DOMでSPAを書くアーキテクチャ
という構成を手軽に作れるようになっていて便利でした これを軸に素のReact APIを触って遊ぶ環境が作れそうです(Server APIもworkerdで動く範囲なら使えるかも?) とりあえず以下のソースコードでデプロイまでできるかを試しました プロジェクトのベースはnpm create hono@latestで作りました DEMO: https://hono-spa-react.pages.dev/ react react-dom @vitejs/plugin-react-swc をnpm installしています デバッグ しかしこの構成だと@hono/vite-dev-serverによるvite devは実行時エラーになり動きません(!) react-dom_client.js?v=f8955f15:11222 Uncaught Error: Objects are not vali
Prettier 3.0 をリリースしました
2023 年 7 月 5 日に Prettier 3.0 をリリースしました。Prettier 2.0 がリリースされたのが 2020 年 3 月 21 日だったので、実に 3 年以上ぶりのメジャーアップデートとなります。 本当はもっと早くこのブログを書きたかったんですが、やる気が出ずだいぶ遅れてしまいました。 この記事では Prettier 3.0 の主要な変更点を紹介します。 Prettier 3.0 の主要な変更点 Prettier 3.0 はメジャーアップデートということもあって大きな変更がいくつか含まれています。ここでは、そのうちユーザーに直接的な影響がありそうなものを紹介します。 ここで紹介する以外にも大きな変更はありますが、プラグイン開発者向けのものとか、Prettier のソースコード自体が全部 ECMAScript Modules で書かれるようになったとか、ユーザーから
Node.js に fetch がやってきた
ブラウザで実行される JavaScript とサーバーサイドで実行される Node.js では提供される API に違いがあります。 例えば DOM を操作する目的で使用する Document.querySelector() は Node.js に存在しないですし、反対にファイルを操作する目的で使用される fs モジュールはブラウザには存在しない API です。 リソースを取得するためのリクエストを実施する Fetch API も同様にブラウザにのみ存在する API でした。 Document.querySelector() のようなそもそも DOM の存在しないサーバーの API として提供されていないのわかりやすいですが、いかにも普遍的に使用できそうな Fetch() が Node.js の API に存在しないというのは初心者にとってはわかりづらく（確かに fetch() はブラウザ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React への依存を最小にするフロントエンド設計
🛑 You don't need passport.js - Guide to node.js authentication ✌️