Node.js 发布了 21.7.0 版本，带来了一些新的特性及 API。

1. util.styleText(format, text): 新 API，用于基于 util.inspect.colors 格式化文本颜色和强调（如红色、蓝色）。

2. process.loadEnvFile(path): 加载 .env 文件的函数；如果没有指定路径，则自动加载当前目录的 .env 文件。

3. .env 文件现在支持多行值，方便配置更为复杂的环境变量。

4. sea: 支持嵌入资产（assets），可以在构建时将各种资产打包到预备 blob 中，并在生成的可执行文件中通过 sea.getAsset() 和 sea.getAssetAsBlob() API 进行获取。

5. vm: 支持使用默认加载器处理动态 `import()`，无需定制加载过程的情况下也能支持编译代码中的动态导入。

6. crypto.hash(): 新增辅助函数，可以一次性计算输入内容的摘要，适合处理较小的直接可用（非流式）输入数据，并减少内存开销。

#NodeJs

https://nodejs.org/en/blog/release/v21.7.0

Joyee 终于在 2024 年为 Node.js 中的 require() 添加了对同步 ES 模块（esm）支持的实验性功能，这是一个许多人期盼已久的特性。在她的博客文章中，Joyee 扩展了她在 pull request 中关于这个特性为何迟迟未能实现的理解。

她解释了 ERR_REQUIRE_ESM 这个错误对 Node.js 生态系统造成的困扰，尤其是对于既要支持 CJS 用户也要支持 ESM 用户的包作者们来说。为了解决这个问题，包作者不得不要么继续发布 CJS 模块，要么同时发布 CJS 和 ESM 版本，并在 package.json 中包含条件导出信息。

此外，许多转译器（例如 TypeScript 编译器）仍然将生成 CJS 代码作为最终输出，这意味着使用这些转译器的用户在写 ESM 语法代码时可能不知道他们的代码最终会被 Node.js 作为 CJS 运行。当这些代码使用真正的 ESM 第三方模块时，他们会遇到无法使用 require() 加载并导致 ERR_REQUIRE_ESM 错误的问题。

有关 ESM 的异步性问题，Joyee 也作出了解释。Node.js 长期以来一直主张不能用 require() 加载 ES 模块，因为 ES 模块具有异步执行特性。但随着 Joyee 对 V8 代码的研究，她发现 ESM 的设计并不是无条件地异步，而是只在图中包含顶层 await 时才是条件性异步的。因此，对于不包含顶层 await 的 ESM 图，Node.js 的 require() 理应至少能够支持它。Joyee 的试验表明，在 npm 注册表中影响力较大的 ESM-only 包中，几乎没有一个包含顶级等待，这表明支持在 require() 中同步模块将大大减少生态系统中的许多困扰。

Joyee 在文章中还特别说明，她表达的是个人意见，不代表任何团体或 Node.js 项目本身。

#NodeJs

https://joyeecheung.github.io/blog/2024/03/18/require-esm-in-node-js/

Node.js 网站的全新设计已经上线，这次的改版既考虑了历史传承，又融入了对未来的展望。作为每日亲密接触并服务于大量用户的重要资源，网站承载着广泛的应用场景和海量的页面内容。这次改造过程虽然遇到过一些挑战，但最终是在三十多位贡献者的共同努力下完成的。新设计改进了信息架构，使内容获取前所未有的便利，并为未来几年创造了一个稳定的开发平台。同时，还提供了改进的开发者体验、更清晰的持续集成/持续部署（CI/CD）反馈和接触更为友好的技术栈。

Node.js 网站自 2008 年以来一直在服务社区，2011 年左右采用了现在的工具下载和文档风格。当时是 Node.js 0.6 版本。网站历史悠久，数据巨大，月请求量高达 300 亿，传输的数据达到 2 PB。

重新设计的第一次尝试开始于 2019 年，在一个新的域名和新的仓库 nodejs.dev 上开始，但这一尝试由于开发分离等多种原因而未能继续。后来，在 2022 年，Claudio Wunder 加入项目团队，将发展方向调整回原有的仓库，并思考如何在确保网站作为珍贵资源的同时重新构建它。

技术栈的选择至关重要。初始阶段选择了 nextra，但随着网站的增长，我们决定自定义设置。最后决定采用 Next.js，因为它的灵活性强。例如，网站仍然是静态构建的，以确保用户速度和基础的托管独立性，但通过 Next.js 的逐步静态重新生成来获取类似发布这样的动态内容。React 也提供了一种与贡献者当前技能集更一致的创作体验。

在这次的重构中，我们与 Vercel 紧密合作，共同克服了在静态导出过程中遇到的 webpack 内存管理问题。在 2023 年 4 月，我们完成了一次小型切换，这是一次重要的里程碑，表明我们能够在运行中重建网站。

在重设计中，Hayden Bleasel 的设计给网站带来了现代感，也方便我们处理多元化的用例。具体实现设计代码的工作由全球的开发者共同完成。

为了迎接 Grace Hopper Celebration 和 Hacktoberfest，我们为新手准备了“good first issues”，并为参与者提供了现场指导和帮助，达到了让新贡献者也可以提交 PR 的目标。

在文档方面，COLLABORATOR_GUIDE、CONTENT_VS_CODE、CONTRIBUTING 等方面进行了迭代或引入新的内容。新代码大量使用 TypeScript，帮助贡献者理解数据的结构和函数预期的行为。

未来计划包括将网站的重设计应用到 API 文档中;探索为网站和 API 文档建立单一仓库;重新开始国际化努力，以应对含有重 markdown/MDX内容的独特挑战;继续改进 CI/CD 流程。感谢所有对重设计做出贡献的人和组织。

#NodeJs

https://nodejs.org/en/blog/announcements/diving-into-the-nodejs-website-redesign

Node.js 技术指导委员会（TSC）明确表示：不打算从官方版本中移除 npm。

Node.js 技术指导委员会 (TSC) 近期就是否默认启用 Corepack 这一话题进行了讨论，并确认了一个重要的共识：没有计划从 Node.js 发行版中移除 npm。这个讨论为 Corepack 的集成和 npm 的未来提供了明确的方向。

通过 Geoffrey Booth TSC 成员的 PR 合并，达成了共识记录，其中明确指出，移除 npm 并非项目目标。另一方面，这也加强了与 npm 客户端的“特殊关系”，确认 npm 是因历史原因以及其作为 npm 注册表的参考实现而被包含在 Node.js 发行版中。

Node.js 更新的技术优先事项文件中新增了 Package Management 一节，强调了 Node.js 将 npm 作为其发行版一部分提供包管理器的原因，这既因 npm 是 JavaScript 软件的主要来源，也因其历史地位——自 2011 年 npm 被纳入时就成为唯一的 JavaScript 包管理器。

此外，对于“Node.js 是否应该自带一个包管理器”的问题，TSC 成员 Myles Borins 建议抛开修辞，从实际角度出发，努力就建筑决策达成共识。Borins 也指出，简单地移除 npm 会在没有明确替代方案的情况下降低 Node.js 的用户体验，强调了目标应是建设性的，而不应是排他性的。

TSC 同时还计划在下周的会议上继续讨论有关“占位符”可执行文件的政策，这与 Node.js 是否将安装用于引用不包括在 Node.js 的二进制文件、脚本等的链接有关。主要考虑的问题是占位符是否会使 Node.js 负有任何由占位符中的安全问题造成的责任。Booth 的 PR 建议，Node.js 不应创建占位符可执行文件（这类命令指代未与 Node.js 一同发行的软件，而是在运行命令时下载软件）。

此次会议预定下一步讨论的内容，以决定 Corepack 相关决策，此决定将有助于处理开放的 PR，其中包括默认启用 yarn 和 pnpm Corepack 二进制文件以及一个关于替代默认启用 Corepack 的提案。这场关于 Corepack 的讨论仍在进行中。

#NodeJs #NPM

https://socket.dev/blog/node-js-tsc-confirms-no-intention-to-remove-npm-from-distribution

Node.js 现在支持在 ES 模块中使用 __dirname 和 __filename 了，这一新变化简化了获取当前模块目录和文件名的方法。这项更新对于从旧的 CommonJS 模块系统切换到 ES 模块的 Node.js 世界来说是一个巨大且持续的变革，解决了这个移动过程中的一个障碍。

在 Node.js 的初期使用 CommonJS 模块系统时，会提供两个变量 __dirname 和 __filename 来返回当前模块的目录名和文件名。但是，在 ES 模块中， __dirname 和 __filename 不再可用。过去，你需要用一些额外的代码来重新实现这两个变量，但这需要记住一些模板代码，而这并不方便。

好消息是，目前 Node.js 20.11.0 版本、Deno 1.40.0 版本以及 Bun 1.0.23 版本之后，你可以直接使用 import.meta 对象的 dirname 和 filename 属性来获取相同的信息。

现在在 ES 模块中可以使用如下代码：

import.meta.dirname  // 获取当前模块的目录名（对应 __dirname）
import.meta.filename // 获取当前模块的文件名（对应 __filename）

重要的是， import.meta.dirname 和 import.meta.filename 只在 import.meta.url 的方案是 "file:" 时可用，即它们在浏览器环境中是不可用的，在浏览器中使用会返回 undefined 。

为了适应这样的改变并实现前后端代码的更好一致性，你可能需要使用 URL 对象而不是路径字符串来执行常见的文件操作。Node.js 的许多 API 不仅可以处理路径字符串，还可以处理 URL 对象。

这样的改动有助于 Node.js 社区、Deno 和 Bun 在采用 ES 模块的代码库移动和新项目启动时减少变革的摩擦，同时在整个生态系统内帮助人们更好地适应变化。最起码，我们现在可以去掉一些重复的模板代码，转而使用 import.meta.dirname 。

#NodeJs

https://www.sonarsource.com/blog/dirname-node-js-es-modules/

Node.js 的 Performance Measurement API 通过 perf_hooks 模块提供了一套工具，用于自动捕获和存储性能指标，并允许开发者主动测量和提升应用程序的性能。文章内容分为以下几个部分：

1. 前提条件：需要基本的 Node.js 知识以及安装了最新版本的 Node.js。

2. Node.js Performance API 概览：API 包括高精度时间、性能时间线、用户计时和资源计时四个主要类别。

3. 高精度时间：介绍了 performance.now() 方法，它提供了不受系统时钟变化影响的单向递增的时间戳。

4. 性能时间线：通过 PerformanceEntry 对象记录程序整个生命周期的性能指标。

5. 用户计时：使用 performance.mark() 和 performance.measure() 方法在性能时间线上添加自定义标记和测量。

6. 资源计时：通过 PerformanceResourceTiming 对象获取与获取资源相关的网络计时数据。

7. perf_hooks API 探索：详细介绍了 PerformanceNodeTiming 、 Performance.now() 、Performance.mark() 、Performance.measure() 、Performance.getEntries() 、 PerformanceObserver 、 `Performance.clearMarks() 、Performance.clearMeasures() 和 PerformanceResourceTiming 等 API 方法和接口。

8. 调整资源计时缓冲区大小：介绍了如何使用 setResourceTimingBufferSize() 方法调整资源计时缓冲区的大小。

#NodeJs #性能

https://betterstack.com/community/guides/scaling-nodejs/performance-apis/

tinyhttp/milliparsec 项目是一个为现代 Node.js 环境构建的极小体积的请求体解析器，该项目自称为“宇宙中最小的请求体解析器”，并且专为现代 Node.js 设计。

#Tools #NodeJs

https://github.com/tinyhttp/milliparsec

WebdriverIO 是一个为 Node.js 设计的下一代浏览器和移动自动化测试框架。它允许基于 WebDriver、WebDriver BiDi 以及 Appium 等自动化技术来运行测试，支持流行的 BDD/TDD 测试框架，并能在本地或云端如 Sauce Labs、BrowserStack、TestingBot 和 LambdaTest 等平台上执行测试。

#Tools #NodeJs

https://github.com/webdriverio/webdriverio

Undici 是一个专为 Node.js 编写的 HTTP/1.1 客户端，从零开始构建，意味着它不依赖于 Node.js 核心模块中的任何现有 HTTP 客户端。

Undici 提供了多种功能，包括但不限于 请求、流、管道 和 升级协议 等，允许开发者以灵活的方式与 HTTP 服务进行交互。它还实现了 Fetch API，使得在 Node.js 环境中可以使用与浏览器相同的接口进行网络请求。Undici 强调性能，支持 TCP 连接的复用，并允许通过配置来启用 HTTP 管道化。

#Tools #NodeJs

https://github.com/nodejs/undici

优化 Node.js 性能：V8 内存管理与垃圾回收调优

Matteo Collina 探讨了 V8 的内存管理和垃圾回收（GC）调优。Node.js 开发者常常会发现应用的内存占用（通过操作系统报告的常驻内存集 RSS 衡量）持续增长，这容易让人误以为是内存泄漏。然而，高 RSS 并不一定意味着内存泄漏，因为 V8 引擎会主动保留从操作系统获取的内存段，即使其中的 JavaScript 对象已被回收，以便为未来的内存分配需求做好准备，从而减少频繁向操作系统请求和释放内存的性能开销。真正意义上的内存泄漏是指那些无法被垃圾回收器回收的不可达 JavaScript 对象，导致应用堆内存中活跃使用的内存不断增加。

Matteo 深入介绍了 V8 的分代垃圾回收机制，基于“代际假说”，即大多数对象在创建后不久就会变成垃圾，而少数存活过初始阶段的对象通常会存活较长时间。V8 将内存堆分为新生代（New Space）和老生代（Old Space）。新生代采用“Scavenge”算法进行快速垃圾回收，它将新生代分为两个相等的半区，当一个半区填满时，Scavenge 周期开始，通过复制存活对象到另一个半区来清理垃圾。而老生代则使用“标记 - 清除”算法，必要时还会进行“压缩”操作以减少内存碎片。如果新生代的内存分配速度超过了 Scavenge 收集器的处理速度，那些本应迅速被回收的对象可能会在一次或两次 Scavenge 周期内存活下来，从而被错误地提升到老生代，这就是“过早晋升”问题。这会导致老生代中充斥着短命对象，使得 V8 不得不更频繁地执行缓慢且资源密集的老生代 GC，从而增加请求延迟并降低应用处理并发请求的能力。

为了解决过早晋升带来的性能问题，开发者可以通过调整 V8 的垃圾回收行为来优化性能，特别是通过调整新生代（New Space）的大小。V8 提供了命令行标志 --max-semi-space-size 来设置每个半区的最大大小（以兆字节为单位）。通过增加新生代的大小，可以为新分配的对象提供更大的缓冲空间，从而让快速的 Scavenge 收集器有更多机会在对象被提升到老生代之前识别并回收它们。这样可以显著减少过早晋升到老生代的频率，进而降低老生代 GC 的频率，减少应用暂停时间，从而改善延迟和吞吐量。

Matteo 还讨论了在 Node.js v22 及更高版本中，V8 默认的新生代半区大小的确定方式发生了变化。新版本的 V8 会根据 Node.js 进程启动时感知到的可用内存总量动态设置默认值。虽然这种动态方法在内存充足的系统上可能表现良好，但在内存受限的环境中（如容器或无服务器平台），可能会导致默认的 --max-semi-space-size 值过小，从而增加过早晋升的可能性。因此，对于在 Node.js v22 或更高版本上运行且内存受限的应用，建议开发者显式设置 --max-semi-space-size 标志，以确保新生代的大小适合其内存分配模式。

Matteo 通过一个实际案例展示了如何通过调整新生代大小来优化性能。在一个包含 Next.js SSR 应用、Fastify 服务器和纯 Node.js 应用的 Watt 应用服务器中，通过将新生代大小调整为 128MB，测试结果显示 P99 延迟降低了 5%，每秒请求数提高了 7%，整体吞吐量提高了 7%。这表明适当调整 V8 的内存管理参数可以显著提升 Node.js 应用的性能。

虽然高 RSS 并不一定意味着内存泄漏，但理解 V8 的内存管理机制并根据应用的具体需求调整垃圾回收策略，可以在内存使用和计算效率之间取得平衡，特别是在内存受限的环境中。

#NodeJs #前端 #性能

https://blog.platformatic.dev/optimizing-nodejs-performance-v8-memory-management-and-gc-tuning

node-base64-image，支持远程 URL 下载图像或使用本地图像并将其编码/解码为 Base64 字符串或 Buffer 对象。

#Tools #前端 #NodeJs

https://github.com/riyadhalnur/node-base64-image

Node.js 24.0.0发布，由 RafaelGSS 和 juanarbol 主导。此版本带来多项重大更新，包括 V8 JavaScript 引擎升级至 13.6 版本，npm 升级至 11 版本，移除对 MSVC 的支持，改为要求使用 ClangCL 在 Windows 上编译 Node.js，AsyncLocalStorage 默认使用 AsyncContextFrame，URLPattern 作为全局变量提供，以及权限模型的改进等。这些更新推动了平台的进一步发展。

V8 13.6 版本引入了多个新的 JavaScript 特性，如 Float16Array、显式资源管理、RegExp.escape、WebAssembly Memory64 和 Error.isError 等。npm 11 版本则带来了性能提升、安全功能增强以及与现代 JavaScript 包的更好兼容性。AsyncLocalStorage 默认使用 AsyncContextFrame，为异步上下文跟踪提供了更高效的实现，提升了性能并使 API 在高级用例中更加稳健。URLPattern 作为全局变量，使得无需显式导入即可使用，为 URL 模式匹配提供了强大的系统。

权限模型的改进体现在，Node.js 20 中引入的实验性权限模型的标志从 --experimental-permission 变更为 `--permission`，表明其稳定性提高并准备更广泛地被采用。测试运行器模块也进行了增强，现在会自动等待子测试完成，无需手动等待测试承诺，使编写测试更加直观，减少了因未处理的承诺而产生的常见错误。

此外，Node.js 24 还包含了 Undici 7 版本，带来了 HTTP 客户端能力的多项改进，包括更好的性能和对更新的 HTTP 特性的支持。在弃用和移除方面，`url.parse()` 被标记为运行时弃用，建议使用 WHATWG URL API 替代；`tls.createSecurePair` 被移除；`SlowBuffer` 被标记为运行时弃用；REPL 实例化时未使用 new 的用法被弃用；Zlib 类未使用 new 的用法被弃用；child_process 中 spawn 和 execFile 的 args 参数传递被弃用。

Node.js 24.0.0 版本还包含了许多其他改进和修复，涉及多个模块和工具。例如，esm 模块支持了 import.meta 属性的正式发布，worker 模块新增了 worker.getHeapStatistics() 方法，util 模块新增了 types.isFloat16Array() 方法，test_runner 模块增加了全局设置和拆卸功能等。这些更新进一步提升了 Node.js 的性能、安全性和易用性，为开发者提供了更强大的工具来构建和维护现代 JavaScript 应用程序。

#NodeJs #新特性

https://nodejs.org/en/blog/release/v24.0.0

Lexe 支持将 Node.js 应用程序打包成单个可执行文件，且文件大小仅约 10MB 。该项目基于 AWS 的轻量级 JavaScript 运行时 LLRT，通过优化和改进，使其能够更高效地支持 Node.js 应用程序的打包和运行。

Lexe 的核心优势在于其轻量级和高性能的特点。与传统的 Node.js 运行时相比，Lexe 去掉了复杂的即时编译器（JIT），从而大幅减少了运行时的体积和启动时间。这种设计使得 Lexe 特别适合用于 Serverless 环境，尤其是在需要快速启动和执行的场景中。例如，在处理数据转换、实时处理、AWS 服务集成、授权和验证等任务时，Lexe 能够提供显著的性能优势。

然而，Lexe 也存在一些限制。由于其不包含 JIT 编译器，因此在处理大规模数据处理、复杂模拟或需要大量迭代的任务时，性能可能会不如传统的 JIT 驱动的运行时。此外，Lexe 目前并不支持完整的 Node.js API，特别是 HTTP 和 HTTPS 模块，而是通过实现 fetch 和 net 等模块来提供网络请求和底层网络服务。因此，它更适合用于构建 CLI 工具，而不是 HTTP 服务。

#NodeJs #Tools

https://github.com/Ray-D-Song/lexe

Node.js v22.18.0 发布

此版本的显著变化是类型剥离功能默认启用，Node.js 现在能够无需额外配置直接执行 TypeScript 文件，例如用户可以创建一个 TypeScript 文件并直接通过 Node.js 运行，但该功能仍处于实验阶段，可通过传递 --no-experimental-strip-types CLI 标志来禁用。

#NodeJs #新特性

https://nodejs.org/en/blog/release/v22.18.0