Node.js、仮想ファイルシステムを実装へ | gihyo.jp
Node.jsのメンテナーであるMatteo Collina氏は2026年3月16日、同氏が設立しCTOを務めるPlatformaticのブログでNode.js向けのユーザーランド仮想ファイルシステム@platformatic/vfsを発表し、あわせてNode.jsのコアに仮想ファイルシステムを統合する予定があることを明かした。 Why Node.js needs a virtual file system -Platformatic Blog platformatic /vfs -GitHub .@nodejs has always been about I/O. Streams, buffers, sockets, files. But there's a gap that has bugged me for years: you can't virtualize the filesy
Announcing Vite+ Alpha
We’re excited to open-source Vite+ under the MIT license. Vite+ is a new unified toolchain and entry point to web application development that manages your runtime, package manager, and frontend toolchain. Give it a try today! What is Vite+? Vite+ combines Vite, Vitest, Oxlint, Oxfmt, Rolldown, and tsdown into a single, unified web development toolchain for developing, testing, linting, formatti
新時代のフロントエンドツールチェイン Vite+ を試してみた
Vite+ は Vite, Vitest, Oxlint, Oxfmt, Rolldown, tsdown といった人気のツールを統合し、開発, テスト, ビルド, リント, フォーマットなどのフロントエンド開発に必要な機能を1つのツールチェインで提供する新しいフロントエンドツールチェインです。この記事では実際に Vite+ をインストールして、プロジェクトのセットアップから開発、テスト、ビルドまでの一連の流れを試してみました。 近年の Web 開発のプロセスはますます複雑化しています。フロントエンドの構築のためには、モジュールバンドラー, トランスパイラー, リンター, テストランナーなど、多くのツールが必要になりますが、設定ファイルも複雑になりがちです。Webpack の設定のために専門の職人が必要になるという話もよく聞きましたね。現代でも .eslintrc, .prettierrc
Node.jsのSingle Executable Applications (SEA) で作る、配布しやすいNode.js アプリ
はじめに Node.js v20 から Single Executable Applications (SEA) が実験的サポートされ、Node.js アプリケーションを単一の実行可能ファイルとして配布できるようになりました。 これにより、Node.js をインストールしていない環境でも Node.js で動作するアプリケーションを簡単に実行できるようになります。 本記事では、SEA を利用して Native Messaging Host を作成し、ブラウザ拡張機能と連携させる例を解説します。 「ブラウザ拡張機能なんて作らないよ！」という方も、SEA としてパッケージングするまでの手順は参考になると思いますので、ぜひ最後までお読みください。 SEA ビルドのフロー SEA ビルドの基本的なフローは以下の通りです。 sea-config.json を作成し、Node.js に読み込ませるため
Webブラウザ上にLinux/Node.sベースのWebアプリ開発環境をWebAssemblyで実装した「BrowserPod」発表。ブラウザ内サーバに別タブからアクセス可能
Webブラウザ上にLinux/Node.sベースのWebアプリ開発環境をWebAssemblyで実装した「BrowserPod」発表。ブラウザ内サーバに別タブからアクセス可能 LearningTechnologiesは、Node.jsによるサーバサイドJavaScriptの実行環境とコードエディタなどの開発環境をWebAssemblyを用いてWebブラウザ上で実行可能にした「BrowserPod」を発表しました。 これによりサーバと接続することなく、WebブラウザだけでフルスタックのWebアプリケーション開発が可能になります。下記の画面にあるように、ViteやSvelteのようにNode.jsに対応したフレームワークも利用できます。 BrowserPodは、WebAssemblyによってx86コマンドをWebAssemblyに変換してWebブラウザで実行可能にする「x86-to-WebAs
fetch() では Host ヘッダーを設定できないし話はそこまで単純じゃない - Object.create(null)
JavaScript (TypeScript) のコードから HTTP リクエストを送る手段として, 最近では Web 標準の一つである Fetch Standard で定義された fetch() が使われることが多いですね. await fetch("https://example.com"); リクエストヘッダーには Host を設定できない Fetch Standard では Host をはじめとして Content-Length, Cookie, Origin など, いくつかのリクエストヘッダーを設定 (JavaScript から上書き) することが禁止されています. https://fetch.spec.whatwg.org/#forbidden-request-header いずれのヘッダーも HTTP やセキュリティ上の取り決めに従うために, ページの JavaSript
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
node --test と Vitest どちらを使うべきか - mizdra's blog
社内で「node --test って実際どうなの?」という議論がありました。その参考に、id:mizdra が node --test 最近を触って思ったことや、感想などを書いてみます。 結論だけ先に書いておくと、node --test はミニマムなテスティングフレームワークです。テストする時に必要とされる機能は大体ありますが、Vitest と比較すると色々欠けてます。そして、Vitest と比べて何が足りないのか、実際に触ってみるまで意外と分からないです。とりあえず動けば OK という人は、Vitest 使ったら良いと思います。node --test はミニマリスト向けです。 node --test とは まず node --test って何という人のために書いておくと、Node.js 組み込みのテストランナーのことです。Node.js v16.17.0, v18.0.0 から導入されて
node:test で jsdoc `@example` に記述したコードを使ってテストする
はじめに 私は vitest を使ってテストコードを実装することが多い。vitest は vite と統合されていることで変換処理に vite と同じプラグインが使えるため、開発時に vite を使っていれば追加で必要な設定が少ないという利点があるのだが、私は In-Source Testing という機能が気に入っていることが大きな理由だ。 これは他の言語でもよくある、実装コードと同じファイル内にテストが記述できるというものだ。 これにはいくつか利点があるが、その中でも、テストを実装の近くに置くことでテストが実装の説明するという役割を強めるという点がある。 このテストが実装の説明する点に注目したときにドキュメント内にテストを書くというアプローチもある。これはドキュメンテーションテストと呼ばれることがあり、いくつかの言語では実装されて用いられている。 vitest においてはプラグインの実
Node.js の進化に伴い不要となったかもしれないパッケージたち
tl;dr はじめに 2024 年の 4 月 24 日に Node.js 22 がリリースされました。ESM を 条件付きで require する機能や、--run フラグによる npm スクリプトのパフォーマンス改善などが v22 で追加され、2009 年に Ryan Dahl が Node.js をリリースしてから 15 年が経つ今も、Node.js は進化を続けています[1]。 こうして Node.js 自身が強化されていくにつれ、以前はサードパーティーのパッケージを使用して実現することが一般的であった機能が Node.js のみで実現可能となり、当該パッケージが不要となるような場合があります。冒頭に引用した Ben Holmes の動画では、そのように不要となったパッケージとして dotenv node-fetch chalk mocha が挙げられていますが、この記事では「これら
Node.js — Node.js 22 is now available!
We're excited to announce the release of Node.js 22! Highlights include require()ing ES modules, a WebSocket client, updates of the V8 JavaScript engine, and more! Node.js 22 will enter long-term support (LTS) in October, but until then, it will be the "Current" release for the next six months. We encourage you to explore the new features and benefits offered by this latest release and evaluate th
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の挙動について整理する。 いきなり書かれても把握できないかもしれないが、一旦こ
Deno first でやっていく
去年末ぐらいから Deno を使う割合がグッと増えてきた。最近のJS関連は7割ぐらい deno 環境の VSCode でコードを書いている気がする。 今回はいくつかの実例を示しながら、実際に Deno 使えるじゃんというイメージを持ってもらうためのユースケースを紹介していく。 というか、 deno が普及してくれないと、自分が作ったツールの紹介を全部 deno のインストールから書かないといけなくなる。みんなインストールしといて。 最初に: なぜ Deno を使いたいか 一番の問題点、Node は新しいプロジェクトを一式整えるための手間が非常に重い。 とくに ts で書いたものを他の環境に渡すための方法が未だにしんどい。ある環境で動いたコードをそのままコピーしても、プロジェクト設定の非互換を踏む可能性が非常に高い。 deno にそういう側面がないとは言わないが、非常に少ない。とくに TS
あたらしいフロントエンド開発ツール「Nue」 | DevelopersIO
About Nue 鵺（ぬえ）。 猿の顔、タヌキの体、蛇の尻尾、虎の脚を持つ妖怪です。 日本人ならNueと聞いた場合、思い浮かべるのは↑かと思うのですが、 これは先日リリースされた、フロントエンド開発ツールセットです。 ＊「Nue」はドイツ語で、「新しい」という意味だそうな *「Nue」はドイツ語の「neu」に由来しており、英語で「新しい」という意味だそうな 開発者はTero Piirainenという方で、 現在彼１人で開発しています。 ここを見ると、「Webの開発方法が変わるかも」と かなりすごいことが書いてありますが、どんなものなのか見ていきましょう。 Nueとはなんなのか？ 公式を見ると、↓のようなことを言っています。 React、Vue、Next.js、Vite、Astroの代わりになる NueはSPAMPAの両方に対するサポートを備えたWebアプリケーションビルダーである Nue
Node.js — Node.js 20.6.0 (Current)
Notable changes built-in .env file support Starting from Node.js 20.6.0, Node.js supports .env files for configuring environment variables. Your configuration file should follow the INI file format, with each line containing a key-value pair for an environment variable. To initialize your Node.js application with predefined configurations, use the following CLI command: node --env-file=config.env
node_modulesの問題点とその歴史 npm, yarnとpnpm
皆さんnpmパッケージのバージョンを上げるときにハマって依存地獄から抜けられなかったことはありませんか？ 私はあります。 複雑怪奇な依存関係を調べてみようとnode_modulesを覗いてみて、そのカオスっぷりに臭いものに蓋をしたことはありませんか？ 私はあります。 そこでnode_modules以下について調べてみたのですが、node_modulesにどんな問題点があって、npmやyarn, pnpmは何を目指していたのか時系列順に紐解いた方がわかりやすいことに気づきました。 ここでは初期のnpmが抱えていた問題から今に至るまでを順を追って説明します。 するとnode_modulesの仕組みの他に、各パッケージマネージャの方針の違いが見えてくるはずです。 初期の頃のnpm (~2015年以前) この頃はシンプルで、依存関係はそのままnode_modulesのディレクトリ構造に反映されてい
CommonJSからES Modulesへの移行する方法。トップダウンかボトムアップか
Secretlint v7でCommonJS からES Modulesへの移行を行いました。 Secretlint v7.0.0をリリースしました。Pure ESMへの書き直し この記事では、CommonJS(CJS)からES Modules(ESM)への移行を行った経緯と、移行する方法について紹介します。 CJSからESMへの移行は、率直に言えば単調な作業で、メリットが見えにくい作業です。 しかし、将来的にCJSよりもESMが主流になることは間違いないので、移行することは必要です。 移行の作業は、移行方法が決まれば大部分は機械的な書き換えが可能です。 では、実際にどうやって移行したのかを紹介します。 ESMへの移行の影響は依存元へと連鎖する Secretlintのリポジトリはmonorepoになっていて、だいたい40コぐらいのパッケージが含まれています。 そしてパッケージ間で依存関係があ
アプリケーションコードに変更を加えないNode.js Native ESMへの移行
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに こんにちは。フロントエンド開発センター(UIT) Front-end Dev.9チームの鴻巣(@kazushikonosu)です。LINEスキマニおよびLINE Creators Marketのフロントエンド開発を担当しています。 LINEスキマニのフロントエンドチームでは、React/TypeScript製のWebアプリを開発しています。主にクライアントサイド向けのコードを扱っていますが、SSRのため同じリポジトリ内でNode.jsを使って実行されるTypeScriptコードも扱っています。クライアントサイドのモジュールバンドラとして長らくwebpackが使われていましたが、webpackを使い続けることでチームの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - unjs/jiti: Runtime TypeScript and ESM support for Node.js
Node Target Mapping
