背景 什么是bundler webpack :强调对web开发的支持，尤其是内置了HMR的支持，插件系统比较强大，对各种模块系统兼容性最佳(amd,cjs,umd,esm等，兼容性好的有点过分了，这实际上有利有弊,导致面向webpack编程），有丰富的生态，缺点是产物不够干净，产物不支持生成esm格式， 插件开发上手较难，不太适合库的开发。 rollup: 强调对库开发的支持，基于ESM模块系统，对tree shaking有着良好的支持，产物非常干净，支持多种输出格式，适合做库的开发，插件api比较友好，缺点是对cjs支持需要依赖插件，且支持效果不佳需要较多的hack，不支持HMR，做应用开发时需要依赖各种插件。 esbuild: 强调性能，内置了对css、图片、react、typescript等内置支持，编译速度特别快（是webpack和rollup速度的100倍+),缺点是目前插件系统较为简单，生态不如webpack和rollup成熟。 bundler如何工作 llvm: 将各个语言通过编译器前端编译到LLVM IR，然后基于LLVM IR做各种优化，然后基于优化后的LLVM IR根据不同处理器架构生成不同的cpu指令集代码。 bundler: 将各个模块先编译为module graph，然后基于module graph做tree shaking && code spliting &&minify等优化，最后将优化后的module graph根据指定的format生成不同格式的js代码。 LLVM和bundler的对比 import lib from './lib';
console.log('lib:', lib);const answer = 42;
export default answer;const rollup = require('rollup');
const util = require('util');
async function main() {
const bundle = await rollup.rollup({
input: ['./src/index.js'],
});
console.log(util.inspect(bundle.cache.modules, { colors: true, depth: null }));
}
main();[
{
code: 'const answer = 42;\nexport default answer;\n',
ast: xxx,
depenencies: [],
id: 'Users/admin/github/neo/examples/rollup-demo/src/lib.js'
...
},
{
ast: xxx,
code: 'import lib from './lib';\n\nconsole.log('lib:', lib);\n',
dependencies: [ '/Users/admin/github/neo/examples/rollup-demo/src/lib.js' ]
id: '/Users/admin/github/neo/examples/rollup-demo/src/index.js',
...
}]const result = await bundle.generate({
format: 'cjs',
});
console.log('result:', result);exports: [],
facadeModuleId: '/Users/admin/github/neo/examples/rollup-demo/src/index.js',
isDynamicEntry: false,
isEntry: true,
type: 'chunk',
code: "'use strict';\n\nconst answer = 42;\n\nconsole.log('lib:', answer);\n",
dynamicImports: [],
fileName: 'index.js',插件系统 onResolve(rollup 里叫resolveId, webpack里叫factory.hooks.resolver): 根据一个moduleid决定实际的的模块地址 onLoad（rollup里叫loadId，webpack里是loader)：根据模块地址加载模块内容) load这里esbuild和rollup与webpack处理有所差异，esbuild只提供了load这个hooks，你可以在load的hooks里做transform的工作，rollup额外提供了transform的hooks，和load的职能做了显示的区分（但并不阻碍你在load里做transform），而webpack则将transform的工作下放给了loader去完成。 这两个钩子的功能看似虽小，组合起来却能实现很丰富的功能。(插件文档这块，相比之下webpack的文档简直垃圾) esbuild插件系统相比于rollup和webpack的插件系统，最出色的就是对于virtual module的支持。我们简单看几个例子来展示插件的作用。loader export const less = (): Plugin => {
return {
name: 'less',
setup(build) {
build.onLoad({ filter: /.less$/ }, async (args) => {
const content = await fs.promises.readFile(args.path);
const result = await render(content.toString());
return {
contents: result.css,
loader: 'css',
};
});
},
};
};sourcemap && cache && error handle let sveltePlugin = {
name: 'svelte',
setup(build) {
let svelte = require('svelte/compiler')
let path = require('path')
let fs = require('fs')
let cache = new LRUCache(); // 使用一个LRUcache来避免watch过程中内存一直上涨
build.onLoad({ filter: /.svelte$/ }, async (args) => {
let value = cache.get(args.path); // 使用path作为key
let input = await fs.promises.readFile(args.path, 'utf8');
if(value && value.input === input){
return value // 缓存命中，跳过后续transform逻辑，节省性能
}
// This converts a message in Svelte's format to esbuild's format
let convertMessage = ({ message, start, end }) => {
let location
if (start && end) {
let lineText = source.split(/\r\n|\r|\n/g)[start.line - 1]
let lineEnd = start.line === end.line ? end.column : lineText.length
location = {
file: filename,
line: start.line,
column: start.column,
length: lineEnd - start.column,
lineText,
}
}
return { text: message, location }
}
// Load the file from the file system
let source = await fs.promises.readFile(args.path, 'utf8')
let filename = path.relative(process.cwd(), args.path)
// Convert Svelte syntax to JavaScript
try {
let { js, warnings } = svelte.compile(source, { filename })
let contents = js.code + `//# sourceMappingURL=` + js.map.toUrl() // 返回sourcemap，esbuild会自动将整个链路的sourcemap进行merge
return { contents, warnings: warnings.map(convertMessage) } // 将warning和errors上报给esbuild，经esbuild再上报给业务方
} catch (e) {
return { errors: [convertMessage(e)] }
}
})
}
}
require('esbuild').build({
entryPoints: ['app.js'],
bundle: true,
outfile: 'out.js',
plugins: [sveltePlugin],
}).catch(() => process.exit(1))virtual module glob import examples
index.html
index.tsx
index.cssimport examples from 'glob:./examples/**/*';
import {vol} from 'memfs';
vol.fromJson(examples,'/'); //将本地的examples目录挂载到memfs 在onResolve里将自定义的path进行解析，然后将元数据通过pluginData和path传递给onLoad，并且自定义一个namespace(namespace的作用是防止正常的file load逻辑去加载返回的路径和给后续的load做filter的过滤） 在onLoad里通过namespace过滤拿到感兴趣的onResolve返回的元数据，根据元数据自定义加载生成数据的逻辑，然后将生成的内容交给esbuild的内置loader处理 const globReg = /^glob:/;
export const pluginGlob = (): Plugin => {
return {
name: 'glob',
setup(build) {
build.onResolve({ filter: globReg }, (args) => {
return {
path: path.resolve(args.resolveDir, args.path.replace(globReg, '')),
namespace: 'glob',
pluginData: {
resolveDir: args.resolveDir,
},
};
});
build.onLoad({ filter: /.*/, namespace: 'glob' }, async (args) => {
const matchPath: string[] = await new Promise((resolve, reject) => {
glob(
args.path,
{
cwd: args.pluginData.resolveDir,
},
(err, data) => {
if (err) {
reject(err);
} else {
resolve(data);
}
}
);
});
const result: Record<string, string> = {};
await Promise.all(
matchPath.map(async (x) => {
const contents = await fs.promises.readFile(x);
result[path.basename(x)] = contents.toString();
})
);
return {
contents: JSON.stringify(result),
loader: 'json',
};
});
},
};
};esbuild基于filter和namespace的过滤是出于性能考虑的，这里的filter的正则是golang的正则，namespace是字符串，因此esbuild可以完全基于filter和namespace进行过滤而避免不必要的陷入到js的调用，最大程度减小golang call js的overhead，但是仍然可以filter设置为/.*/来完全陷入到js，在js里进行过滤，实际的陷入开销实际上还是能够接受的。memory virtual module let envPlugin = {
name: 'env',
setup(build) {
// Intercept import paths called "env" so esbuild doesn't attempt
// to map them to a file system location. Tag them with the "env-ns"
// namespace to reserve them for this plugin.
build.onResolve({ filter: /^env$/ }, args => ({
path: args.path,
namespace: 'env-ns',
}))
// Load paths tagged with the "env-ns" namespace and behave as if
// they point to a JSON file containing the environment variables.
build.onLoad({ filter: /.*/, namespace: 'env-ns' }, () => ({
contents: JSON.stringify(process.env),
loader: 'json',
}))
},
}
//
import { NODE_ENV } from 'env' // env为虚拟模块，function virtual module build.onResolve({ filter: /^fib((\d+))/ }, args => {
return { path: args.path, namespace: 'fib' }
})
build.onLoad({ filter: /^fib((\d+))/, namespace: 'fib' }, args => {
let match = /^fib((\d+))/.exec(args.path), n = +match[1]
let contents = n < 2 ? `export default ${n}` : `
import n1 from 'fib(${n - 1}) ${args.path}'
import n2 from 'fib(${n - 2}) ${args.path}'
export default n1 + n2`
return { contents }
})
// 使用方式
import fib5 from 'fib(5)' // 直接编译器获取fib5的结果，是不是有c++模板的味道stream import import { Plugin } from 'esbuild';
import { fetchPkg } from './http';
export const UnpkgNamepsace = 'unpkg';
export const UnpkgHost = 'https://unpkg.com/';
export const pluginUnpkg = (): Plugin => {
const cache: Record<string, { url: string; content: string }> = {};
return {
name: 'unpkg',
setup(build) {
build.onLoad({ namespace: UnpkgNamepsace, filter: /.*/ }, async (args) => {
const pathUrl = new URL(args.path, args.pluginData.parentUrl).toString();
let value = cache[pathUrl];
if (!value) {
value = await fetchPkg(pathUrl);
}
cache[pathUrl] = value;
return {
contents: value.content,
pluginData: {
parentUrl: value.url,
},
};
});
build.onResolve({ namespace: UnpkgNamepsace, filter: /.*/ }, async (args) => {
return {
namespace: UnpkgNamepsace,
path: args.path,
pluginData: args.pluginData,
};
});
},
};
};
// 使用方式
import react from 'react'; //会自动在编译器转换为 import react from 'https://unpkg.com/react' 本地开发： 完全走本地file加载，即都走file namespace 本地开发免安装node_modules: 即类似deno和snowpack的streaming import的场景，可以通过业务文件走file namespace,node_modules文件走unpkg namespace,比较适合超大型monorepo项目开发一个项目需要安装所有的node_modules过慢的场景。 web端实时编译场景(性能和网络问题)：即第三方库是固定的，业务代码可能变化，则本地file和node_modules都走memfs。 web端动态编译:即内网webide场景，此时第三方库和业务代码都不固定，则本地file走memfs，node_modules走unpkg动态拉取 我们发现基于virtual module涉及的universal bundler非常灵活，能够灵活应对各种业务场景，而且各个场景之间的开销互不影响。universal bundler rollup treeshaking支持非常好，也支持cjs的tree shaking 丰富的插件hooks，具有非常灵活定制的能力 支持运行在浏览器上 支持多种输出格式(esm,cjs,umd,systemjs) 正式因为上述优良的特性，所以很多最新的bundler|bundleness工具都是基于rollup或者兼容rollup的插件体系，典型的就是 vite 和wmr, 不得不说给rollup写插件比起给webpack写插件要舒服很多。 我们早期的universal bundler实际上就是基于rollup开发的，但是使用rollup过程中碰到了不少问题，总结如下对CommonJS的兼容问题 循环引用问题 动态require的hoist问题 Hybrid CJS和ESM 性能问题 浏览器上cjs转esm virutual module的支持 filesystem node module resolution file|index|目录三种情形 js、json、addon多文件后缀 esm和cjs loader区别 main field处理 conditional exports处理 exports subpath NODE_PATH处理 递归向上查找 symlink的处理 除了node module resolution本身的复杂，我们可能还需要考虑main module filed fallback、alias支持、ts等其他后缀支持等webpack额外支持但在社区比较流行的功能，yarn|pnpm|npm等包管理工具兼容等问题。自己从头实现这一套算法成本较大，且node 的module resolution算法一直在更新，webpack的enhanced-resolve 模块基本上实现了上述功能，并且支持自定义fs，可以很方便的将其移植到memfs上。我觉得这里node的算法着实有点over engineering而且效率低下（一堆fallback逻辑有不小的io开销），而且这也导致了万恶之源hoist盛行的主要原因，也许bare import配合import map，或者deno|golang这种显示路径更好一些。main field cjs和esm，esnext和es5，node和browser，dev和prod的入口该怎么配置 module| main 里的代码应该是es5还是esnext的（决定了node_module里的代码是否需要走transformer） module里的代码是应该指向browser的实现还是指向node的实现（决定了node bundler 和browser bundler情况下main和module的优先级问题） node和browser差异的代码如何分发处理等等 unpkg shim 与 polyfill 一种是这些模块依赖的实际就是些node的utily api例如utils、path等，这些模块实际上并不依赖node runtime,此时我们实际上是可以在浏览器上模拟这些api的，browserify实际上就是为了解决这种场景的，其提供了大量的node api在浏览器上的polyfill如path-browserify,stream-browserify等等， 另一种是浏览器和node的逻辑分开处理，虽然node的代码不需要在浏览器上执行，但是不期望node的实现一方面增大浏览器bundle包的体积和导致报错，此时我们需要node相关的模块进行external处理即可。 一个小技巧，大部分的bundler配置external可能会比较麻烦或者没办法修改bundler的配置，我们只需要将require包裹在eval里，大部分的bundler都会跳过require模块的打包。如eval('require')('os')polyfill与环境嗅tan，矛与盾之争 webassembly 我们可以在哪里使用esbuild minifier transformer bundler 更高效的register和minify工具 更高效的prebundle工具 更好的线上cjs2esm服务 node bundler 减小了使用方的node_modules体积和加快安装速度，相比将node应用的一堆依赖一起安装到业务的node_modules里，只安装bundle的代码大幅减小了业务的安装体积和加快了安装速度，pnpm和yarn就是使用esbuild将所有依赖bundle实现零依赖的正面典型https://twitter.com/pnpmjs/status/1353848140902903810?s=21 提高了冷启动的速度，因为bundle后的代码一方面通过tree shaking减小了引起实际需要parse的js代码大小（js的parse开销在大型应用的冷启动速度上占据了不小的比重，尤其是对冷启动速度敏感的应用），另一方面避免了文件io，这两方面都同时大幅减小了应用冷启动的速度，非常适合一些对冷启动敏感的场景，如serverless 避免上游的semver语义破坏，虽然semver是一套社区规范，但是这实际上对代码要求非常严格，当引入了较多的第三方库时，很难保证上游依赖不会破坏semver语义，因此bundle代码可以完全避免上游依赖出现bug导致应用出现bug，这对安全性要求极高的应用（如编译器）至关重要。 因此笔者十分鼓励大家对node应用进行bundle，而esbuild对node的bundle提供了开箱即用的支持。tsc transformer替代品 monorepo与monotools
esbuild存在的一些问题 调试麻烦 只支持target到es6 golang wasm的性能相比native有较大的损耗，且wasm包体积较大， 插件api较为精简 
游戏开发
发布于：2022-02-09 10:29
|
阅读数：300
|
评论：0
QQ好友和群
QQ空间
