Nestjs 开发环境热更新的方案
Nestjs 的热更新是基于 Webpack HMR（Hot-Module Replacement) 方案
警告
请注意，webpack不会自动将您的资产(例如graphql文件)复制到dist文件夹。同样，webpack与glob静态路径(例如TypeOrmModule中的实体属性)不兼容。
1 使用 CLI
如果您正在使用Nest CLI，配置过程非常简单。CLI包装webpack，它允许使用HotModuleReplacementPlugin。
安装
首先安装依赖包:
$ npm i --save-dev webpack-node-externals
配置
在根目录下创建 webpack.config.js，内容如下:
const webpack = require('webpack');
const nodeExternals = require('webpack-node-externals');
module.exports = function(options) {
return {
...options,
entry: ['webpack/hot/poll?100', './src/main.ts'],
watch: true,
externals: [
nodeExternals({
whitelist: ['webpack/hot/poll?100'],
}),
],
plugins: [...options.plugins, new webpack.HotModuleReplacementPlugin()],
};
}
此函数获取包含默认webpack配置的原始对象，并返回一个修改后的对象，该对象带有一个已应用的HotModuleReplacementPlugin插件。
Hot-Module Repacement
为了启用HMR，打开应用程序入口文件(main.ts)并添加几个与webpack相关的指令，如下所示:
declare const module: any;
async function bootstrap() {
const app = await NestFactory.create(AppModule);
await app.listen(3000);
if (module.hot) {
module.hot.accept();
module.hot.dispose(() => app.close());
}
}
bootstrap();
在 package.json文件中增加如下两条脚本
"build": "nest build --watch --webpack"
"start": "node dist/main",
执行如下命令
$ npm run build
Webpack 开始监听文件，再新的命令行窗口执行
$ npm run start
不使用 CLI
安装
$ npm i --save-dev webpack webpack-cli webpack-node-externals ts-loader
配置
创建 webpack.config.js 内容如下:
const webpack = require('webpack');
const path = require('path');
const nodeExternals = require('webpack-node-externals');
module.exports = {
entry: ['webpack/hot/poll?100', './src/main.ts'],
watch: true,
target: 'node',
externals: [
nodeExternals({
whitelist: ['webpack/hot/poll?100'],
}),
],
module: {
rules: [
{
test: /.tsx?$/,
use: 'ts-loader',
exclude: /node_modules/,
},
],
},
mode: 'development',
resolve: {
extensions: ['.tsx', '.ts', '.js'],
},
plugins: [new webpack.HotModuleReplacementPlugin()],
output: {
path: path.join(__dirname, 'dist'),
filename: 'server.js',
},
};
Hot-Module Replacement
为了启用HMR，打开应用程序入口文件(main.ts)并添加几个与webpack相关的指令，如下所示:
declare const module: any;
async function bootstrap() {
const app = await NestFactory.create(AppModule);
await app.listen(3000);
if (module.hot) {
module.hot.accept();
module.hot.dispose(() => app.close());
}
}
bootstrap();
在 package.json 文件中加入以下脚本
"webpack": "webpack --config webpack.config.js"
"start": "node dist/server",
执行命令
$ npm run webpack
新命令窗口下执行
$ npm run start
Typeorm 配置
由于webpack与glob静态路径不兼容，所以要想让 typeorm 同样支持热更新，正常需要静态引入 entity 而不是利用通配符方式。
如：
import { Cat } from '../cat/cat.entity';
@Module({
imports: [
// provides: typeorm/Connection, typeorm/EntityManager
TypeOrmModule.forRoot({
entities: [
Cat,
],
}),
],
})
export class DatabaseModule { }
但是这样如果有很多 entity 会非常不便，幸运的是，webpack有一特性 require.context。允许收集所需文件的上下文。那么我们可以这样：
// entity.context.ts (in root src folder)
export const entityContext = require.context('.', true, /\.entity\.ts$/);
// database.module.ts
import { entityContext } from '../entity.context';
@Module({
imports: [
TypeOrmModule.forRoot({
entities: [
...entityContext.keys().map(id => {
const entityModule = entityContext(id);
// We must get entity from module (commonjs)
// Get first exported value from module (which should be entity class)
const [entity] = Object.values(entityModule);
return entity;
})
],
}),
],
})
export class DatabaseModule { }
但这个方案，对 production 不友好，所以还可以使用下面的方案:
import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { getMetadataArgsStorage } from 'typeorm';
// The modules are loaded from here, hence importing the entities
import { AModule } from './a/a.module';
import { BModule } from './b/b.module';
@Module({
imports: [
AModule,
BModule,
TypeOrmModule.forRoot({
...,
entities: getMetadataArgsStorage().tables.map(tbl => tbl.target),
migrations: ...,
}),
]
})
export class AppModule {}
这个方案的思路是：
由于webpack将所有代码打包成一个单独的包文件，为了让HMR工作，这个包文件作为服务器加载并运行指定实体:* dirname + '/*/。ts'将导致typeorm需要那些文件(而实际的实体已经在webpack包中加载了)。
当typeorm试图获取repository时，它会将传入的实体与从js/ts文件中加载的实体配置进行比较(例如，从webpack包中加载用户的getRepository)。
尽管它们有相同的名称，但它们是从不同的模块加载的两个不同的类(函数)，因此typeorm将无法找到正确的类。
我的解决方案是基于所有模块都已加载的事实，因此应该已经通过导入加载了所有实体。对于结构良好的项目，NestJS尤其如此。具体来说，对于每个模块，要么模块本身，要么控制器将导入实体到某个地方。
通过利用@Entity装饰器的内部机制，我们将能够获得实体类的列表。
不确定这个是最佳方案，但的确运行良好。
