DenoとNode.jsは両方ともV8をバックエンドにしたサーバーサイドJavaScriptランタイムだが、そこには大きな違いが存在するkeroxp.icon
DenoとNode.jsは両方ともV8をバックエンドにしたサーバーサイドJavaScriptランタイムだが、そこには大きな違いが存在するkeroxp.icon
Changing the End-of-Life Date for Node.js 16 to September 11th, 2023 Summary We are moving the End-of-Life date of Node.js 16 by seven months to coincide with the end of support of OpenSSL 1.1.1 on September 11th, 2023. Why? When we put together Node.js 16 the hope was that we would be able to include OpenSSL 3. Unfortunately, the timing of the releases did not allow that to be possible, and we re
はじめに このガイドでは、Node.jsのコードのビルドとテストを行う継続的インテグレーション(CI)ワークフローの作成方法を紹介します。 CIテストにパスしたなら、コードをデプロイしたりパッケージを公開したりすることになるでしょう。 前提条件 Node.js、YAML、ワークフローの設定オプションと、ワークフローファイルの作成方法についての基本的な知識を持っておくことをおすすめします。 詳細については、次を参照してください。 「ワークフローの書き込み」 "Node.js の使用を開始する" Node.js スターター ワークフローの使用 すぐに開始するには、リポジトリの .github/workflows ディレクトリにスターター ワークフローを追加します。 GitHub では、ほとんどの Node.js プロジェクトで動作できる Node.js 用のスターター ワークフローを提供してい
Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。本稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり
TypeScript 4.7 がリリースされたので、Node.js ESM 対応の現状をまとめておく。 @teppeis さんの TypeScript 4.5 以降で ESM 対応はどうなるのか? を先に読んでおくと、以降の話も読み進めやすいかも。 このエントリの中でも、teppeis さんの定義した用語をそのまま用いさせてもらう。 * CommonJS (CJS): 従来式の Node.js CommonJS で書かれたファイルまたはパッケージ * ES Modules (ESM): ES2015 で定義されたモジュール仕様。Node.js では v12 以降でネイティブにサポートされている。 * Native ESM: ESM 形式で記述されたファイルを、Node.js またはブラウザで直接 ESM として実行する方式またはそのファイル。擬似 ESM と区別するために Native と
Login to Meetup | Meetup Find groups that host online or in person events and meet people in your local community who share y... ECMAScript Modules とは? JavaScript には、AMD や UMD、CJS のような多くのモジュールシステムがあります。 ECMAScript Modules は当初 ES2015 に入る予定でした。 さて、ESM の仕様は WHATWG と TC39 が管理しますが、役割が違います。 TC39 は ESM のシンタックスや JS のルールを管理します。 例えば、モジュールは strict mode になるとか、thisの扱いとか。 しかし、モジュールの読み込みに関しては、WHATWG が管理します。 理由は、
こんにちは。フロントエンドエキスパートの平野(@shisama_)です。 フロントエンドエキスパートチームでは業務時間の 30 % の時間で技術探究を行っています。 今回は探究した技術の中から Node.js の ES Modules(以下 ESM)についてと Dual Package (CommonJS/ES Modules) に対応した npm パッケージの開発について紹介します。 ES Modules の特徴 ESM はブラウザ互換 ESM は Strict モード ESM は非同期 ESM は静的解析可能 Node.js の ESM 対応について Dual Package(CJS/ESM)に対応した npm パッケージの開発 Conditional Exports によるファイルの指定 .mjs と .cjs require など CJS 特有の機能を使う ESMから CJS ファ
記事執筆時点での最新版の Node.js では、モジュールシステムとして ES Modules を使うことができる。 また、CommonJS で書かれたモジュールを ES Modules で読み込むこともできる。 Node.js のモジュールシステムは複雑すぎて苦手意識があったので、整理した。 この記事の内容は、Node.js のv14.7.0で動作確認している。 Node.js のモジュールシステムはバージョン毎に挙動が大きく変わるので、注意が必要。 そのファイルは CJS なのか ESM なのか Node.js で使えるモジュールシステムとして、ES Modules(以下、ESM)の他に CommonJS(以下、CJS)があり、CJS がデフォルトになっている。 Node.js におけるモジュールシステムを理解するためにはまず、Node.js が各ファイルをどのモジュールシステムとして
Node.js アドベントカレンダーの 3 日目の記事です。空きを埋める形で始めました。 qiita.com www.codegrid.net CodeGrid でも書かせていただきましたが、 Node.js で ES Module / CommonJS を使ってコアライブラリのロードをする際、 node から始まる scheme を付けることが可能になっています。 nodejs.org // ESM import fs from "node:fs/promises"; // CJS const http = require("node:http"); これにはいくつかのメリットがあります。基本的につけておくことが望ましいです。 今回はメリットをいくつか紹介します。まだこれがデファクト・スタンダードになっている訳ではありませんが、これから付けてもらうように推奨していきたいと思います。 メリ
先日 import.meta について調査して人に話す機会があり HTML(Web) と Node.js の各ホストの import.meta がどのようなオブジェクトを返すのかを調査していた。そのときは、「HTML でも Node.js でも import.meta.url だけが生えていて〜〜」という話をしてしまった。 後になって知ったのだが、Node.js には import.meta.url 以外にも import.meta.resolve というプロパティが実装されている。 この記事では Node.js に実装されている import.meta.resolve について解説する。 なお、import.meta.url はまだ Stability 1 の API なので、今後仕様が変わる可能性があることに注意してほしい。 import.meta について まず import.met
3 行で Node.js >= v14.14.0 であること rimraf dist は node -e 'fs.rmSync(`dist`, {recursive:true, force:true})' で置き換えられる rimraf dist/*.bundle.js みたいな glob を含むものは置き換えできない 長い説明 npm scripts で不要なキャッシュやビルドの出力ファイルを削除したい場合は rimraf というパッケージを POSIX の rm -rf の代わりに使うことが多いと思います。これは Windows で npm run の実行に使われる コマンドプロンプト (cmd.exe) に rm がないのを始めとした環境依存の問題を避けるためです。 とはいえパッケージなしではディレクトリの再帰的削除もできない、というのはちょっと困るので、v12.10.0 で fs.
The exports field in the package.json of a package allows to declare which module should be used when using module requests like import "package" or import "package/sub/path". It replaces the default implementation that returns main field resp. index.js files for "package" and the file system lookup for "package/sub/path". When the exports field is specified, only these module requests are availab
We’re excited to announce that Node.js 18 was released today! Highlights include the update of the V8 JavaScript engine to 10.1, global fetch enabled by default, and a core test runner module. Initially, Node.js 18 will replace Node.js 17 as our ‘Current’ release line. As per the release schedule, Node.js 18 will be the 'Current' release for the next 6 months and then promoted to Long-term Support
Intro ちょうどタコピーの原罪が流行ってるのでこのタイトルにしたけど結構気に入ってる。 d.potato4d.me この話を読んでの感想とここまで大きくなった Node.js の振り返りをしようと思う。 どんなプログラミング言語であってもみんなから使ってもらって開発者をハッピーにしたいと思ってる。ただ最初は良かったと思ってた機能がなんか古臭くなったり、他にクールな機能を持ったものが登場したことによって徐々に飽きられていき、最終的に他の言語に乗り換えられる。 まぁどんな言語も同じだと思う。C言語だって生まれた当初はすごくクールでみんなをハッピーにしてた。今丁度「戦うプログラマー」を読んでるが、C++が出てきて、周りのエンジニアが C++ を使おうとするシーンが出てくる。そこで、「あんなの使って何が良いんだ、Cで十分だろ」とWindows NT 開発リーダーのデーブカトラーが言ってたりする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く