跳到主要内容

Release 3.20.0

· 阅读需 3 分钟
Harry Chen
Harry Chen
Maintainer of Midway

升级请参考 如何更新 Midway 中描述，请不要单独升级某个组件包。

本次 3.20 版本，主要引入了全新的 BullMQ 组件，作为 Bull 组件的升级替代，提供了更好的性能和更多的功能。

下面是更为细节的描述。

BullMQ 组件​

从 v3.20 开始，我们引入了全新的 BullMQ 组件，作为 Bull 组件的下一代实现。BullMQ 提供了更好的性能和更丰富的功能，包括：

  • 更好的类型支持
  • 更强大的任务流（Flow Producer）功能
  • 更完善的事件系统
  • 更灵活的任务处理机制

基础使用示例：

// 定义任务处理器
@Processor('test')
export class TestProcessor implements IProcessor {
  async execute(data: any) {
    // 处理任务逻辑
    console.log('processing job:', data);
  }
}

// 执行任务
const testQueue = this.bullmqFramework.getQueue('test');
await testQueue?.runJob({
  name: 'harry'
});

任务流示例：

// 创建任务流
const flowProducer = bullmqFramework.createFlowProducer({}, 'test-flow');

await flowProducer.add({
  name: 'flow-test',
  queueName: 'flow-queue-1',
  data: { value: 1 },
  children: [
    {
      name: 'child-job',
      queueName: 'flow-queue-2',
      data: { value: 2 }
    }
  ]
});

更多的内容，请参考 BullMQ 组件文档。

Bull 组件迁移提示​

从 v3.20 开始，我们推荐使用 BullMQ 组件替代原有的 Bull 组件。虽然 Bull 组件仍然可用，但我们建议在新项目中使用 BullMQ，并逐步将现有项目迁移到 BullMQ。

主要的变化包括：

  1. 配置方式的调整
// Bull
export default {
  bull: {
    defaultQueueOptions: {
      redis: {
        port: 6379,
        host: '127.0.0.1',
      },
    }
  },
}

// BullMQ
export default {
  bullmq: {
    defaultConnection: {
      port: 6379,
      host: '127.0.0.1',
    },
  },
}
  1. Worker 和事件处理
// BullMQ 新增了独立的 Worker 和 QueueEvents
const worker = bullmqFramework.createWorker(
  'queueName',
  async (job) => {
    // 处理任务
  }
);

const queueEvents = queue.createQueueEvents();
queueEvents.on('completed', ({ jobId }) => {
  console.log(`Job ${jobId} completed!`);
});
  1. 任务流支持
// BullMQ 支持创建任务依赖关系
const flowProducer = bullmqFramework.createFlowProducer();
await flowProducer.add({
  name: 'flow-test',
  queueName: 'flow-queue-1',
  children: [/* 子任务 */]
});
  1. 队列操作的增强
// BullMQ 提供了更多队列操作方法
const queue = bullmqFramework.createQueue('test');
await queue.runJob(data);              // 执行任务
await queue.createQueueEvents();       // 创建事件监听
await queue.createQueueEventsProducer(); // 创建事件生产者

其他更新​

  • typeorm 组件现在可以指定自定义的 DataSource 了，以支持一些自定义数据源的场景
  • 更新了一些依赖库以提高安全性和稳定性

更多的更新内容和详细信息，请参考我们的 ChangeLog。

Release 3.19.0

· 阅读需 3 分钟
Harry Chen
Harry Chen
Maintainer of Midway

升级请参考 如何更新 Midway 中描述，请不要单独升级某个组件包。

本次 3.19 版本，主要引入了 Kafka 组件的重构，以及一些性能优化和 bug 修复。

下面是更为细节的描述。

Kafka 组件重构​

从 v3.19 开始，Kafka 组件进行了重构，配置和使用方法与之前有较大差异。虽然原有的使用方式仍然兼容，但文档不再保留。新的 Kafka 组件提供了更灵活的配置和更强大的功能。

// src/config/config.default.ts
export default {
  kafka: {
    consumer: {
      sub1: {
        connectionOptions: {
          clientId: 'my-app',
          brokers: ['localhost:9092'],
        },
        consumerOptions: {
          groupId: 'groupId-test-1',
        },
        subscribeOptions: {
          topics: ['topic-test-1'],
        }
      },
    },
    producer: {
      clients: {
        pub1: {
          connectionOptions: {
            clientId: 'my-app',
            brokers: ['localhost:9092'],
          },
          producerOptions: {
            // ...
          }
        }
      }
    }
  }
}

更多的内容，请参考 Kafka 组件文档。

Mock 功能分组​

从 3.19.0 开始，Midway 的 mock 功能支持通过分组来管理不同的 mock 数据。你可以在创建 mock 时指定一个分组名称，这样可以在需要时单独恢复或清理某个分组的 mock 数据。

import { mockContext, restoreMocks } from '@midwayjs/mock';

it('should test mock with groups', async () => {
  const app = await createApp();

  // 创建普通对象的 mock
  const a = {};
  mockProperty(a, 'getUser', async () => {
    return 'midway';
  }, 'group1');

  // 创建上下文的 mock
  mockContext(app, 'user', 'midway', 'group1');
  mockContext(app, 'role', 'admin', 'group2');

  // 恢复单个分组
  restoreMocks('group1');

  // 恢复所有分组
  restoreAllMocks();
});

通过分组，你可以更灵活地管理和控制 mock 数据，特别是在复杂的测试场景中。

新增了一个启动性能分析的命令​

在开发环境下，新增了一个 perf-init 命令，用于在启动时初始化性能分析，需要配合最新的 mwtsc 一同使用。

{
  "scripts": {
    "dev": "cross-env NODE_ENV=local mwtsc --watch --run @midwayjs/mock/app.js --perf-init"
  }
}

其他更新​

  • 更新了一些依赖库以提高安全性和稳定性。

更多的更新内容和详细信息，请参考我们的 ChangeLog。

Release 3.18.0

· 阅读需 2 分钟
Harry Chen
Harry Chen
Maintainer of Midway

升级请参考 如何更新 Midway 中描述，请不要单独升级某个组件包。

本次 3.18 版本，主要修复了新的 busboy 组件的一些遗留问题，以及新增了一种上传模式。

下面是更为细节的描述。

异步迭代器上传模式​

为了支持单次多个文件的流式上传，新版本使用了异步迭代器模型转换了上传流，这个新的模式用于替代原有的流式模式。

// src/config/config.default.ts
export default {
  // ...
  busboy: {
    mode: 'asyncIterator',
  },
}

装饰器的入参也已经变成了异步迭代器。

import { Controller, Post, Files, Fields } from '@midwayjs/core';
import { UploadStreamFileInfo, UploadStreamFieldInfo } from '@midwayjs/busboy';

@Controller('/')
export class HomeController {

  @Post('/upload', /*...*/)
  async upload(
    @Files() fileIterator: AsyncGenerator<UploadStreamFileInfo>,
    @Fields() fieldIterator: AsyncGenerator<UploadStreamFieldInfo>
  ) {
    // ...
  }
}

我们可以通过循环迭代器获取到每个上传的文件。

for await (const file of fileIterator) {
  const { filename, data } = file;
  // ...
}

进而可以方便的做后续处理。

更多的内容，请参考 细节文档。

此外还有更多的变化​

  • 流式上传时的 fieldName 字段现在恢复了
  • httpClient 现在默认的配置不再会被单次请求覆盖
  • 数据源的优先级 NPE 报错现在已经修复了
  • 业务中的 https 配置现在在 dev 的输出提示中也变得正常了

以及一大批依赖进行了更新，可以参考我们的 ChangeLog。

Release 3.17.0

· 阅读需 5 分钟
Harry Chen
Harry Chen
Maintainer of Midway

升级请参考 如何更新 Midway 中描述，请不要单独升级某个组件包。

本次 3.17 版本，我们增加了一些新的特性，以及修复了一些问题，主要有：

  • 1、使用 替换原有的上传组件
  • 2、busboy 上传的数据中的 filedName，在流式模式下不再提供
  • 3、增加了一个新的服务端响应格式
  • 4、class 中间件现在可以复用了

下面是更为细节的描述。

定制服务端响应格式​

在 3.17 版本中，我们增加了一个新的特性，可以定制服务端的响应的通用格式。

在之前的版本中，我们依靠中间件和过滤器来实现这个功能，但是这种方式有一些局限性，代码也会分散在不同的地方。

如果由一个统一的可调整的返回逻辑，可能更为合理，为此，添加了 ServerResponse 和 HttpServerResponse 的实现。

import { ServerResponse, HttpServerResponse } from '@midwayjs/core';

@Controller()
export class HomeController {
  @Inject()
  ctx: Context;

  @Get('/')
  async index() {
    return new HttpServerResponse(this.ctx).json({
      success: true,
      data: 'hello world',
    });
  }
}

HttpServerResponse 是 ServerResponse 的一个 Http 实现，提供了一些常用的方法。

最为特殊的是他可以针对不同的数据格式，设置成功和失败的模版。

比如针对 JSON 数据，框架提供了以下的默认结构。

HttpServerResponse.JSON_TPL = (data, isSuccess) => {
  if (isSuccess) {
    return {
      success: 'true',
      data,
    };
  } else {
    return {
      success: 'false',
      message: data || 'fail',
    };
  }
};

这样，当返回 JSON 格式时，就会按照这个模版进行返回。

// 失败的返回
return new HttpServerResponse(this.ctx).fail().json('hello world');

就会获取到以下的数据。

{
  success: 'false',
  message: 'hello world',
}

此外，基于这个模式，也同时实现了 SSE 的响应返回，也有其他的一些数据结构的返回，更多的内容，请参考 细节文档。

上传组件​

由于在小文件场景下上传碰到一些问题，从 v3.17 开始，基于 busboy 实现了一个新的上传组件，替换原有的 @midwayjs/upload。

和原有的组件比有一些不同。

  • 1、不再默认加载中间件，因为上传只是少部分接口的特殊逻辑，不需要全局加载
  • 2、配置的 key 为了避免冲突，从 upload 变为 busboy

其余的使用方式和原有的上传组件一致，

更多细节请访问 文档。

类中间件复用​

在之前，如果需要复用中间件，只能使用函数中间件。

const mw = (ctx, next) => {
  // ...
}

@Controller(/**/)
export class HomeController {

  @Get('/', { middleware: [mw]})
  async home() {}
  
  @Get('/api', { middleware: [mw]})
  async api() {}
}

但是如果希望用上继承，或者 match 和 ignore 功能的，则是类的行为更为方便。

这个版本框架提供了 createMiddleware 功能，保留原有的逻辑同时，可以创建出一个新的中间件实例。


@Middleware()
export class ReportMiddleware implements IMiddleware<Context, NextFunction> {
  // ...
}

@Controller(/**/)
export class HomeController {

  @Get('/', { middleware: [createMiddleware(ReportMiddleware, {}, 'name1')]})
  async home() {}
  
  @Get('/api', { middleware: [createMiddleware(ReportMiddleware, {}, 'name2')]})
  async api() {}
}

通过向 createMiddleware 传递不同的参数，以及中间件名字，就可以引用到不同的逻辑。

更多的细节，请查看 Web中间件 文档。

更多的变化​

  • 修复了一个多语言匹配 key 的问题
  • 一些不合理类型定义的调整

以及一大批依赖进行了更新，可以参考我们的 ChangeLog。

mwtsc 增加版本检查

· 阅读需 2 分钟
Harry Chen
Harry Chen
Maintainer of Midway

由于 Midway 版本发布规则，@midwayjs/core 和组件有着版本对应关系，即低版本的 @midwayjs/core 无法使用高版本的组件。

比如 @midwayjs/axios@3.17.0 可能使用了高版本的 API，是无法在 @midwayjs/core@3.16.0 版本上执行的。

由于 npm 等包管理的特性，包安装时不存在联系，npm i @midwayjs/axios 时往往只会安装组件最新的版本，非常容易造成兼容性问题。

为此我们提供了 npx midway-version 命令，可以快速检查版本之间的兼容性错误。

在推行一阵子之后，我们发现很少有用户主动去执行这样的指令，只会在出错时被动执行，再加上锁包和不锁包的复杂场景，会出现一些很难复现和排查的现象。

为了降低复杂性，在 mwtsc 新版本的启动阶段，我们也加入了检查代码。

如果出现不兼容的版本，工具会进行提示。

此外，新增的 npx midway-version -m 指令可以让固化版本的用户也享受到更新工具。

和之前的 -u 指令不同，-m 会使用当前的 @midwayjs/core 版本，更新组件到最兼容的版本，而不是最新版本。

结合 mwtsc 和 midway-version 工具，可以更简单的管理版本，如有问题可以反馈给我们改进。