尧图网页设计 
webpack 5 如何以 target 为 bun 构建应用并处理 node 内置模块【免费下载链接】webpackA bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through loaders, modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.项目地址: https://gitcode.com/GitHub_Trending/web/webpack如果你的应用最终跑在 Bun 运行时上用 webpack 打包时会遇到一个具体矛盾源码里会用到path、url这类 node 内置模块也可能用到bun:sqlite、bun:ffi这类只有 Bun 才提供的模块而它们都不在node_modules里webpack 默认解析时会直接构建失败。webpack 5.108.0 引入了buntarget见 CHANGELOG.md为这个场景提供了一组开箱即用的处理构建产物固定为 ESMnode 内置模块和bun:*模块全部保持 external由 Bun 运行时在加载 bundle 时解析。当前仓库中 webpack 的版本是 5.110.3package.json。bun target 到底做了什么实现集中在 lib/bun/BunTargetPlugin.js它在 lib/WebpackOptionsApply.js 中被挂载——触发条件是options.externalsPresets.bun而这个开关由 target 推导见下文。它对三类请求分别处理源码中的请求处理方式path、url等 node 内置模块裸名改写成node:path形式的 externalnode:前缀的写法原样保留bun、bun:sqlite、bun:ffi等 Bun 内置模块保持 external由 Bun 运行时提供绝不打包Bun全局对象不做任何处理——不打包、不 shim、不改名作为 free global 留在 bundle 里两个值得知道的事实node 内置模块的判定名单来自 lib/node/nodeBuiltins.js 的coreModules与 deno target 共用同一份列表。源码注释说明改写为node:形式的原因Bun 对path和node:path两种写法都能解析所以统一输出带前缀的形式lib/bun/BunTargetPlugin.js。target: bun会让experiments.outputModule默认为true也就是说bun target 只产出 ECMAScript 模块lib/config/defaults.js。另外解析时bun会被加入 package exports 的 resolve conditions并且优先级高于nodelib/config/defaults.js——如果某个包的package.json声明了exports.bun条件构建出的 bundle 会走这个入口。配置 webpack最小配置就是把target设为bun并指定入口。由于 bun target 下 ESM 输出是默认值这里不需要写experiments.outputModule// webpack.config.js module.exports { target: bun, entry: ./main.js };仓库里的测试用例例如 test/configCases/bun/node-builtins/webpack.config.js写得更完整module.exports { target: bun, // The harness picks the bundle extension from the raw config (before the // bun targets ESM default applies), so set ESM output explicitly. experiments: { outputModule: true }, output: { module: true } };注意那段注释显式声明 ESM 是测试 harness 的要求——harness 在默认值生效之前就要根据原始配置决定 bundle 的文件扩展名。普通项目里target: bun已经默认开启 ESM 输出但如果你的外部工具链同样在读取“默认值生效前”的原始配置照这份写法显式声明两个字段就是稳妥的做法。构建并验证webpack 包自带 CLIpackage.json 声明了bin/webpack.js在已安装 webpack 的项目里执行npx webpack构建能否成功本身就是一层验证bun:sqlite、bun:ffi这类模块在磁盘上不存在一旦 webpack 误将其打包构建阶段就会解析失败。仓库用下面的断言用例验证构建产物可以直接照搬成自己的检查清单。node 内置模块走node:形式加载test/configCases/bun/node-builtins/index.jsimport { basename } from path; import { fileURLToPath } from url; it(should load node.js built-ins through the node: specifier, () { expect(basename(/foo/bar/baz.js)).toBe(baz.js); expect(typeof fileURLToPath).toBe(function); });Bun 标准 API 保持为运行时全局test/configCases/bun/standard-api/index.jsit(should keep Buns standard API available as a global, () { expect(typeof Bun).toBe(object); expect(typeof Bun.version).toBe(string); expect(typeof Bun.file).toBe(function); });Bun 内置模块保持 external 且可解析test/configCases/bun/bun-builtins/index.jsimport { Database } from bun:sqlite; import { dlopen } from bun:ffi; it(keeps buns built-in modules external and resolvable, () { expect(typeof Database).toBe(function); expect(typeof dlopen).toBe(function); });这些用例只在 Bun 运行时下执行用例的 test.filter.js 返回typeof Bun ! undefined非 Bun 环境直接跳过而bun-builtins用例额外提供了 test.config.js用 stub 模块让断言也能离线跑在 Node 上。你可以在自己的项目里用bun run dist/main.js直接执行 bundle对照上面的断言检查。代码分割与 exports 条件异步 chunk 在 bun target 下走原生import()加载仓库有对应的回归用例test/configCases/bun/code-splitting/index.jsit(should load an async chunk via native import(), async () { const { value } await import(./chunk); expect(value).toBe(42); });该用例的配置额外声明了optimization: { chunkIds: named }得到可读的 chunk 文件名方便调试test/configCases/bun/code-splitting/webpack.config.js。bunexports 条件的优先级由 test/configCases/bun/exports-condition/index.js 守护依赖包同时声明exports.bun和exports.node时bun target 构建出的 bundle 必须解析到 bun 专属入口。如果你的依赖包提供了运行时专属入口可以用同样的断言确认构建走的是哪一条。限制产物固定为 ESMbun target 下experiments.outputModule默认truelib/config/defaults.js文档中没有 CommonJS 产物路径。外部化范围只有两类node 内置模块coreModules名单内的裸名会被改写成node:形式和bun/bun:*模块第三方 npm 包照常打包。运行验证依赖 Bun 运行时本身——测试用例用typeof Bun ! undefined判定是否执行没有 Bun 就只能跑带 stub 的离线变体。如果你的目标不是单一 Bun 运行时而是一个 bundle 同时跑在浏览器、Node、Deno、Bun 等多个环境仓库提供了另一条路径examples/universal 展示的target: universal它产出平台无关的 ESM bundle平台相关行为在运行时解析。想深入实现细节从 lib/bun/BunTargetPlugin.js 出发再对照 test/configCases/bun 下各用例的webpack.config.js与断言文件即可。【免费下载链接】webpackA bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through loaders, modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.项目地址: https://gitcode.com/GitHub_Trending/web/webpack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 webpack 5 如何以 target 为 bun 构建应用并处理 node 内置模块
webpack 5 如何以 target 为 bun 构建应用并处理 node 内置模块【免费下载链接】webpackA bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through loaders, modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.项目地址: https://gitcode.com/GitHub_Trending/web/webpack如果你的应用最终跑在 Bun 运行时上用 webpack 打包时会遇到一个具体矛盾源码里会用到path、url这类 node 内置模块也可能用到bun:sqlite、bun:ffi这类只有 Bun 才提供的模块而它们都不在node_modules里webpack 默认解析时会直接构建失败。webpack 5.108.0 引入了buntarget见 CHANGELOG.md为这个场景提供了一组开箱即用的处理构建产物固定为 ESMnode 内置模块和bun:*模块全部保持 external由 Bun 运行时在加载 bundle 时解析。当前仓库中 webpack 的版本是 5.110.3package.json。bun target 到底做了什么实现集中在 lib/bun/BunTargetPlugin.js它在 lib/WebpackOptionsApply.js 中被挂载——触发条件是options.externalsPresets.bun而这个开关由 target 推导见下文。它对三类请求分别处理源码中的请求处理方式path、url等 node 内置模块裸名改写成node:path形式的 externalnode:前缀的写法原样保留bun、bun:sqlite、bun:ffi等 Bun 内置模块保持 external由 Bun 运行时提供绝不打包Bun全局对象不做任何处理——不打包、不 shim、不改名作为 free global 留在 bundle 里两个值得知道的事实node 内置模块的判定名单来自 lib/node/nodeBuiltins.js 的coreModules与 deno target 共用同一份列表。源码注释说明改写为node:形式的原因Bun 对path和node:path两种写法都能解析所以统一输出带前缀的形式lib/bun/BunTargetPlugin.js。target: bun会让experiments.outputModule默认为true也就是说bun target 只产出 ECMAScript 模块lib/config/defaults.js。另外解析时bun会被加入 package exports 的 resolve conditions并且优先级高于nodelib/config/defaults.js——如果某个包的package.json声明了exports.bun条件构建出的 bundle 会走这个入口。配置 webpack最小配置就是把target设为bun并指定入口。由于 bun target 下 ESM 输出是默认值这里不需要写experiments.outputModule// webpack.config.js module.exports { target: bun, entry: ./main.js };仓库里的测试用例例如 test/configCases/bun/node-builtins/webpack.config.js写得更完整module.exports { target: bun, // The harness picks the bundle extension from the raw config (before the // bun targets ESM default applies), so set ESM output explicitly. experiments: { outputModule: true }, output: { module: true } };注意那段注释显式声明 ESM 是测试 harness 的要求——harness 在默认值生效之前就要根据原始配置决定 bundle 的文件扩展名。普通项目里target: bun已经默认开启 ESM 输出但如果你的外部工具链同样在读取“默认值生效前”的原始配置照这份写法显式声明两个字段就是稳妥的做法。构建并验证webpack 包自带 CLIpackage.json 声明了bin/webpack.js在已安装 webpack 的项目里执行npx webpack构建能否成功本身就是一层验证bun:sqlite、bun:ffi这类模块在磁盘上不存在一旦 webpack 误将其打包构建阶段就会解析失败。仓库用下面的断言用例验证构建产物可以直接照搬成自己的检查清单。node 内置模块走node:形式加载test/configCases/bun/node-builtins/index.jsimport { basename } from path; import { fileURLToPath } from url; it(should load node.js built-ins through the node: specifier, () { expect(basename(/foo/bar/baz.js)).toBe(baz.js); expect(typeof fileURLToPath).toBe(function); });Bun 标准 API 保持为运行时全局test/configCases/bun/standard-api/index.jsit(should keep Buns standard API available as a global, () { expect(typeof Bun).toBe(object); expect(typeof Bun.version).toBe(string); expect(typeof Bun.file).toBe(function); });Bun 内置模块保持 external 且可解析test/configCases/bun/bun-builtins/index.jsimport { Database } from bun:sqlite; import { dlopen } from bun:ffi; it(keeps buns built-in modules external and resolvable, () { expect(typeof Database).toBe(function); expect(typeof dlopen).toBe(function); });这些用例只在 Bun 运行时下执行用例的 test.filter.js 返回typeof Bun ! undefined非 Bun 环境直接跳过而bun-builtins用例额外提供了 test.config.js用 stub 模块让断言也能离线跑在 Node 上。你可以在自己的项目里用bun run dist/main.js直接执行 bundle对照上面的断言检查。代码分割与 exports 条件异步 chunk 在 bun target 下走原生import()加载仓库有对应的回归用例test/configCases/bun/code-splitting/index.jsit(should load an async chunk via native import(), async () { const { value } await import(./chunk); expect(value).toBe(42); });该用例的配置额外声明了optimization: { chunkIds: named }得到可读的 chunk 文件名方便调试test/configCases/bun/code-splitting/webpack.config.js。bunexports 条件的优先级由 test/configCases/bun/exports-condition/index.js 守护依赖包同时声明exports.bun和exports.node时bun target 构建出的 bundle 必须解析到 bun 专属入口。如果你的依赖包提供了运行时专属入口可以用同样的断言确认构建走的是哪一条。限制产物固定为 ESMbun target 下experiments.outputModule默认truelib/config/defaults.js文档中没有 CommonJS 产物路径。外部化范围只有两类node 内置模块coreModules名单内的裸名会被改写成node:形式和bun/bun:*模块第三方 npm 包照常打包。运行验证依赖 Bun 运行时本身——测试用例用typeof Bun ! undefined判定是否执行没有 Bun 就只能跑带 stub 的离线变体。如果你的目标不是单一 Bun 运行时而是一个 bundle 同时跑在浏览器、Node、Deno、Bun 等多个环境仓库提供了另一条路径examples/universal 展示的target: universal它产出平台无关的 ESM bundle平台相关行为在运行时解析。想深入实现细节从 lib/bun/BunTargetPlugin.js 出发再对照 test/configCases/bun 下各用例的webpack.config.js与断言文件即可。【免费下载链接】webpackA bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through loaders, modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.项目地址: https://gitcode.com/GitHub_Trending/web/webpack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考