Webpack 在使用 multicompiler 时性能较差。 特别是,它是由手表引起的(
watch: true
),因为它们消耗大量系统资源,可能会导致如下错误:
<--- Last few GCs --->
[29700:0000022696A23110] 869488 ms: Mark-sweep 4009.8 (4138.0) -> 3997.0 (4141.2) MB, 1671.9 / 0.0 ms (average mu = 0.449, current mu = 0.024) allocation failure; scaveng
e might not succeed
[29700:0000022696A23110] 872444 ms: Mark-sweep 4013.0 (4141.2) -> 4000.1 (4144.2) MB, 2919.2 / 0.0 ms (average mu = 0.224, current mu = 0.012) allocation failure; scaveng
e might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF630979E7F node_api_throw_syntax_error+175967
2: 00007FF630900C06 SSL_get_quiet_shutdown+65750
3: 00007FF630901FC2 SSL_get_quiet_shutdown+70802
4: 00007FF63139A214 v8::Isolate::ReportExternalAllocationLimitReached+116
5: 00007FF631385572 v8::Isolate::Exit+674
6: 00007FF6312073CC v8::internal::EmbedderStackStateScope::ExplicitScopeForTesting+124
7: 00007FF6312045EB v8::internal::Heap::CollectGarbage+3963
8: 00007FF63121A823 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath+2099
9: 00007FF63121B0CD v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath+93
10: 00007FF63122A903 v8::internal::Factory::NewFillerObject+851
11: 00007FF630F1BEB5 v8::internal::DateCache::Weekday+1349
12: 00007FF6314378B1 v8::internal::SetupIsolateDelegate::SetupHeap+558193
13: 00007FF6313BAE63 v8::internal::SetupIsolateDelegate::SetupHeap+47651
14: 00007FF5B37BB7A3
Process finished with exit code 134
就我而言,我将 Webpack 与 Gulp 一起使用(但是,没有
webpack-steram
)。
我已经有了 .js
和 .ts
文件的 Gulp 观察程序,如果可以触发 Webpack 编译器,这将是解决方案。
const webpackCompilers: Webpack.MultiCompiler = webpack(
[
{ entry: './index1.js', output: { filename: 'bundle1.js' } },
{ entry: './index2.js', output: { filename: 'bundle2.js' } },
],
(err, stats) => {
process.stdout.write(stats.toString() + '\n');
}
);
gulp.watch(
"*.ts",
(callback: () => void): void => {
webpackCompilers.run((): void => {
// ...
callback();
});
}
};
虽然有
run
方法,但我不确定它会执行冷启动(不是解决方案),还是会增量重建(将是解决方案)。
我有 3 个编译器:一个用于前端(浏览器运行时),一个用于后端(NodeJS 运行时),一个用于 Posgres 数据源(NodeJS 运行时,但必须公开导入)。 AFAIK,由于预设不兼容,通过单个 Webpack 编译器完成此类操作是不可能的。使用 3 个编译器,我们有 3 个观察器、3 个 TypeScript 类型检查器和 3 个 ES linter。即使在我的高规格计算机(64Gb RAM)中,项目构建也将花费超过 1 分钟,并且重建也会很慢(将无法工作)。
我已经将 linting 委托给 Gulp 并实现了缓存。 多亏了它,我对所有文件都进行了单一优化的 linter。 但要在增量构建期间重新运行此 linting,需要额外的 Gulp 观察器。
接下来必须做的是将监视委托给 Gulp(本问题的主题),并将 TyepScript 类型检查委托给 Gulp。
虽然有
方法,但我不确定它会执行冷启动(不是解决方案),还是会增量重建(将是解决方案)。run
您仍然可以测试 webpack.run()。
假设 Webpack 5 在内存或文件系统中缓存配置,Webpack 应该记住它构建的模块和块,从而有助于更快的后续构建。 Webpack 5 的持久缓存功能可以通过在文件系统上存储缓存信息来进一步增强增量构建,即使在冷启动时也允许增量构建。
module.exports = {
// Other configuration
cache: {
type: 'filesystem', // Enable filesystem caching
buildDependencies: {
config: [__filename], // Invalidate cache when configuration changes
},
},
};
然后您可以定义 webpack 编译器并在 Gulp 任务中使用它们来监视更改并触发增量构建:
Gulp Watchers --(triggers)--> Webpack Compilers
| |
|---- Watches .ts and .js files |---- Handles incremental builds
|---- Triggers rebuild on change |---- Outputs bundles
|
└---- Also handles linting and TypeScript type checking
你会使用:
const gulp = require('gulp');
const webpack = require('webpack');
// Define your Webpack compilers for different targets
const webpackCompilers = webpack([
{ entry: './index1.js', output: { filename: 'bundle1.js' } },
{ entry: './index2.js', output: { filename: 'bundle2.js' } },
]);
// Gulp task to watch changes in .ts files and trigger Webpack compilation
gulp.task('watch-ts-files', () => {
gulp.watch('*.ts', (done) => {
webpackCompilers.run((err, stats) => {
if (err) {
console.error('Webpack compilation error:', err);
} else {
console.log(stats.toString({
colors: true,
modules: false,
children: false,
chunks: false,
chunkModules: false
}));
}
done(); // Signal completion of the task
});
});
});
webpackCompilers.run
方法会触发新的编译,并且由于Webpack的缓存机制已经到位,因此它只会重建已更改的内容,从而导致更快的增量构建。