<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Node on Commentary of Takao</title><link>https://takao.blog/en/tags/node/</link><description>Recent content in Node on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sat, 13 Jun 2026 23:11:50 +0900</lastBuildDate><atom:link href="https://takao.blog/en/tags/node/index.xml" rel="self" type="application/rss+xml"/><item><title>Node.js Stable Support for Requiring ESM Modules</title><link>https://takao.blog/en/web/node-esm-require-support-stable/</link><pubDate>Wed, 05 Nov 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/node-esm-require-support-stable/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Node.js Stable Support for Requiring ESM Modules" /&gt;&lt;h2 id="nodejs-stable-support-for-requiring-esm-modules"&gt;Node.js Stable Support for Requiring ESM Modules
&lt;/h2&gt;&lt;p&gt;For years, Node.js developers faced a painful divide: &lt;strong&gt;CommonJS&lt;/strong&gt; (CJS) and &lt;strong&gt;ES Modules&lt;/strong&gt; (ESM) coexisted with limited interoperability. CJS code could &lt;code&gt;import()&lt;/code&gt; ESM modules asynchronously, but &lt;code&gt;require()&lt;/code&gt; — the synchronous loading mechanism at the heart of CJS — could not load ESM at all. This forced codebase migrations to be all-or-nothing affairs.&lt;/p&gt;
&lt;p&gt;That changed with Node.js 22 and 23, which stabilized the &lt;code&gt;--experimental-require-module&lt;/code&gt; flag. As of Node 23, synchronous &lt;code&gt;require()&lt;/code&gt; can load ES modules, provided the ESM graph does not use top-level await.&lt;/p&gt;</description></item><item><title>ESM vs CommonJS Interop Challenges in Node.js</title><link>https://takao.blog/en/web/node-esm-cjs-interoperability/</link><pubDate>Fri, 25 Jul 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/node-esm-cjs-interoperability/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post ESM vs CommonJS Interop Challenges in Node.js" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Node.js has supported ECMAScript Modules (ESM) since v12, but the ecosystem remains deeply rooted in CommonJS (CJS). Mixing the two module systems in a single project — or consuming CJS packages from ESM code — introduces subtle pitfalls around exports, default imports, and globals. This article maps the interop boundary and provides concrete strategies for a smooth migration.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="cjs-vs-esm-at-a-glance"&gt;CJS vs ESM at a Glance
&lt;/h2&gt;&lt;table&gt;
	&lt;thead&gt;
			&lt;tr&gt;
					&lt;th&gt;Aspect&lt;/th&gt;
					&lt;th&gt;CommonJS&lt;/th&gt;
					&lt;th&gt;ESM&lt;/th&gt;
			&lt;/tr&gt;
	&lt;/thead&gt;
	&lt;tbody&gt;
			&lt;tr&gt;
					&lt;td&gt;File extensions&lt;/td&gt;
					&lt;td&gt;&lt;code&gt;.js&lt;/code&gt;, &lt;code&gt;.cjs&lt;/code&gt;&lt;/td&gt;
					&lt;td&gt;&lt;code&gt;.js&lt;/code&gt;, &lt;code&gt;.mjs&lt;/code&gt;&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;Default in &lt;code&gt;package.json&lt;/code&gt;&lt;/td&gt;
					&lt;td&gt;&lt;code&gt;&amp;quot;type&amp;quot;: &amp;quot;commonjs&amp;quot;&lt;/code&gt;&lt;/td&gt;
					&lt;td&gt;&lt;code&gt;&amp;quot;type&amp;quot;: &amp;quot;module&amp;quot;&lt;/code&gt;&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;Loading&lt;/td&gt;
					&lt;td&gt;Synchronous (&lt;code&gt;require()&lt;/code&gt;)&lt;/td&gt;
					&lt;td&gt;Asynchronous (&lt;code&gt;import&lt;/code&gt;)&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;Top-level &lt;code&gt;this&lt;/code&gt;&lt;/td&gt;
					&lt;td&gt;&lt;code&gt;module.exports&lt;/code&gt;&lt;/td&gt;
					&lt;td&gt;&lt;code&gt;undefined&lt;/code&gt;&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;&lt;code&gt;__dirname&lt;/code&gt; / &lt;code&gt;__filename&lt;/code&gt;&lt;/td&gt;
					&lt;td&gt;Available&lt;/td&gt;
					&lt;td&gt;Not available&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;Live bindings&lt;/td&gt;
					&lt;td&gt;Copy exports&lt;/td&gt;
					&lt;td&gt;Live bindings&lt;/td&gt;
			&lt;/tr&gt;
	&lt;/tbody&gt;
&lt;/table&gt;
&lt;hr&gt;
&lt;h2 id="configuring-the-module-system"&gt;Configuring the Module System
&lt;/h2&gt;&lt;p&gt;You control the module system via the &lt;code&gt;package.json&lt;/code&gt; &lt;code&gt;&amp;quot;type&amp;quot;&lt;/code&gt; field:&lt;/p&gt;</description></item><item><title>Comparing Package Managers: npm, pnpm, and yarn</title><link>https://takao.blog/en/web/npm-pnpm-yarn-package-managers/</link><pubDate>Tue, 15 Apr 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/npm-pnpm-yarn-package-managers/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Comparing Package Managers: npm, pnpm, and yarn" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;In JavaScript and Node.js development, package managers are essential daily tools.&lt;/p&gt;
&lt;p&gt;While &lt;strong&gt;npm&lt;/strong&gt; remains the default industry standard, modern alternatives like &lt;strong&gt;pnpm&lt;/strong&gt; (famous for saving disk space and speed) and &lt;strong&gt;yarn&lt;/strong&gt; (featuring zero-installs and Plug&amp;rsquo;n&amp;rsquo;Play modes) offer distinct architectures.&lt;/p&gt;
&lt;p&gt;Although they resolve the same &lt;code&gt;package.json&lt;/code&gt; specifications, their internal storage structures, dependency resolutions, and security features differ. This article compares these three package managers to help you choose the best tool for your next project.&lt;/p&gt;</description></item></channel></rss>