Node.jsのリリースチームは、これまで6カ月ごとに年に2回行われていたNode.jsのリリースを年に1回とし、すべてのリリースがLTS版になることを発表しました。 毎年4月にリリースされ、安定化期間を経てLTSに移行 現在までNode.jsは毎年4月に偶数バージョンがリリースされ、10月には奇数バージョンがリリースされるという年2回のリリースが行われています。 そして偶数バージョンは長期サポート（LTS：Long Term Support）版として、通常は合計30か月間にわたり重大なバグに対する修正が保証されます。 今回の発表は、この年に2回のリリースを見直して1回にする、というものです。具体的には10月のリリースがなくなり、4月のリリースのみとなります。 そして4月にリリースされたバージョンは、半年間の安定化期間を経て、10月から長期サポート期間に移行します。これが毎年繰り返されるた
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
こんにちは、藤吾郎（gfx）と申します。Starleyという会社でおしゃべりAIアプリ「Cotomo」を開発しています。TypeScript歴は10年くらいです。 はじめに - TypeScriptが当たり前になった世界今年（2025年）はTypeScriptがリリースされて13年、ESモジュールが導入されたES2015のリリースから10年が経ちます。今やJavaScriptプロジェクトにおいては、TypeScriptが当たり前の世界になってきました。つまり「JavaScriptプロジェクトの実装言語のデフォルトはTypeScript」という状況にかなり近づいています。 TypeScriptが当たり前の世界とは、JavaScript処理系がデフォルトでTypeScriptをサポートしている世界のことです。Node.jsでTypeScriptサポートが始まり、BunやDenoのように最初から
tsconfig.json を使うと、型チェックを緩く/強くしたり、また出力する JS の形式を変えたりできる。しかしいくつかの事情から、正しく書くのが難しい。 オプションの数が非常に多い その数なんと 133 個 *1 オプションの意味や役割が理解しにくい 公式ドキュメントは丁寧にかかれているが... JavaScript や TypeScript の仕様、型の知識、歴史的経緯などを知らないと理解しづらい 推奨されるオプションが変わっていく 言語やエコシステムの進化/変化によって変わる 最近だと Node.js の TypeScript サポートで変わった 「オプションの細かい意味とかは一旦いいから、モダンで最小限の tsconfig.json がすぐに欲しい！！！」。そうした声に応えて、id:mizdra がオススメする「4 ステップでモダンな tsconfig.json を作る方法」
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
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
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
現在のブラウザは、いちどカメラやPUSH通知の権限要求を拒否すると、その後要求プロンプトを出すことができません。 Webサイトができることは、『〇〇を許可してください』とウィンドウを出すことくらいです。 ↓人類史上最悪の許可要求ウィンドウの例 この後設定欄から各機能を有効化するためには、ユーザによる絶対的能動的な操作が必要となります。 また、プライバシーとセキュリティ設定から許可しない設定をしておくと、たったの一度すらもチャンスが与えられず、一生権限を要求することはできません。 結果としてPUSH通知の権限要求などは、9割以上のユーザが拒否するという当然の事態になっています。 ということで、一度拒否したとしても権限を再度要求できるようにする動きが水面下で画策されています。 以下は該当の提案、Page Embedded Permission Control (PEPC)のざっくり紹介です。
（2025/03/01追記） 2025/03/01にTypeScript 5.8がリリースされたので記事を更新しました。 TypeScript 5.8で導入されたerasableSyntaxOnlyフラグを使うと、enumやnamespace、クラスのパラメータプロパティ、moduleキーワードなどの構文をエラーとして検出できます。これらの構文はNode.jsでTypeScriptを実行する際に非互換な構文であり、本フラグの導入によりNode.jsとTypeScriptの互換性が高まります。 本記事では、erasableSyntaxOnlyフラグの挙動と、なぜこのフラグが導入されたのかを解説します。 erasableSyntaxOnlyフラグの挙動 erasableSyntaxOnly とは、「削除可能な構文のみ」という意味です。削除可能な構文とは、Node.jsでTypeScriptを実
こんにちは。リファクタリングが大好きなフロントエンドおじさん梅津です。 自信を持ってリファクタリングするには信頼できる自動テストが必要ですよね。 じゃあ信頼できる自動テストとはなんだろう？どう書いたらいいんだろう？と考えていました。 とくにコンポーネントを含む UI テストに対しての悩みが強かったです。 そんなときに出会ったのが Testing JavaScript です。 この記事ではその Testing JavaScript の紹介をしたいと思います。 Testing JavaScript とは Testing JavaScript は PayPal のエンジニアである Kent C. Dodds によって作成された教材です。 ページを開いてすぐ目に飛び込んでくるテスティングトロフィーが特徴的ですね。 Testing JavaScript では、ここに記されている Static, Un
単体テストを書く時、モジュール間の関連を検証するため、一部のモジュールをモックする必要が出てくることがあります。モックは様々な手法がありますが、書き方によって、メンテナンス性やテストの可読性が変わります。一般的に行われるモック手法を確認しつつ、よりリーダブルなテストを書く方法を紹介します。 ログイン 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を利用する。 環境 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 はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
はじめに 昨日ファイルを扱う実装をしている際、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が提案してくれたのに、これらが何を機能するものなのか、その詳細を理解していなかったため、ここでそれらについて調
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にインストールしておく必要があります。今回はMacにて動作を確認しました。 まず「docker-compose.yml」ファイルについてです。以下のようになり、Typescriptの
laisoさんが書いてたのほぼなんだけど Honoは文字列でもStreamでもなんでも返せるからサーバーサイドもReactで書けるし、tsconfig.jsonで適切に設定すればJSXなんでもいけるし、Viteのdev-serverがあるから、サーバーもクライントも同時に開発、ビルドできて、もちろんAPIを生やすのが得意で、雑React SPA環境（API付き！）作るのに向いてるよ。 作り方解説します。めんどい人はここにプロジェクト作ってるからclone、ダウンロードしてください。 まず、create-honoして、cloudflare-pagesのテンプレートを選ぶ。bunをパッケージマネージャーに使ってる。
という構成を手軽に作れるようになっていて便利でした これを軸に素の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
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 で書かれるようになったとか、ユーザーから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
