[Feature request] 废弃遍历文件夹的启动方式

[zanminkian]

The feature, motivation（功能、动机）

目前midway启动文件（bootstrap.js）如下：

const { Bootstrap } = require('@midwayjs/bootstrap');
Bootstrap.run();

我没看过midway的源码，但我盲猜应该是@midwayjs/bootstrap这个包会遍历本地的dist文件夹或者src文件夹，然后将controller和provider等找出来，构建ioc容器。

这种方式很黑盒。看起来和java的spring很像，但是一点也不js。目前js主流还是用静态导入导出，包括react、nest等生态。

这种遍历至少有如下问题：

1. 性能问题，如果我项目文件夹很深，对项目启动可能有影响。
2. 未来node肯定会学deno增加本地文件权限控制（已经试验性支持了），从追随主流的角度，也不应该滥用fs扫描。
3. 不能使用ncc打包成单文件。
4. 使用npx ts-prune来查找dead code不方便，想要删除不用的代码太麻烦。
5. 过分黑盒，用户需要理解，node bootstrap.js是去遍历dist文件夹，ts-node bootstrap.js是去遍历src文件夹。
6. ESM兼容问题，比如是否支持mts、cts等文件后缀？比如esm的export和export default等兼容，这些都要在@midwayjs/bootstrap里面处理，还不如遵循规范，交给用户，@midwayjs/bootstrap模块就接收controllers和providers等数组就行了

Alternatives（替代方案）

1. 废弃遍历文件夹的启动方式
2. 提供static和dynamic方式，默认static，要求用户传递controller、provider等数组。dynamic模式则和当前类似去遍历文件夹

Additional context（其他上下文）

No response

[waitingsong]

开发、编译的时候是会遍历，生产环境是直接读取 js 文件以及装饰器相关 meta，不会有遍历行为的

[zanminkian]

现在midway的编译可以直接tsc，并且也官方推荐tsc（这一点遵循node社区主流，值得点赞），直接tsc并不会导出meta信息。

[waitingsong]

我的 midwayjs 项目就是直接用 tsc 编译的，dist 目录的代码带有 meta 信息

[zanminkian]

不可能吧。你说的meta信息是指legacy装饰器编译成js代码后的那些helper函数吧。而我的意思是require('@midwayjs/bootstrap').run()这段代码会内部调用fs模块遍历dist文件夹下的js文件地址，然后动态require(controllerPath)。这种遍历文件夹再动态加载的方式不好。

[czy88840616]

就目前看来，大部分人都不喜欢自己维护这种静态的加载关系，我们的组件是强制使用了这种加载，而业务代码部分保留了动态遍历以方便研发。

当然这种也是可以开关的，比如：

// bootstrap.js
const { Bootstrap } = require('@midwayjs/bootstrap');
const { ReportMiddlware, HomeController } = require('./dist/report.middleware');
Bootstrap.configure({
  // 预加载文件
  preloadModules: [ReportMiddlware, HomeController],
  // 停止文件扫描
  detector: false,
}).run();

不过这样做了之后，在开发期就需要自己处理 dist 下文件的问题，引进来比较恶心的。另外，dev 的时候由于走的是 mock/app，可能就得换成 bootstrap.js 了，以及如果是 cjs/esm文件，也需要自行处理。

另外原本文件加载时框架是可以做一些hook，比如后续的 HMR 机制就是靠 hook 文件来做的，如果走这个方式，开发的时候也就没法做了。

nestjs 那样做，是需要依靠每个文件的依赖关系，做初始化，内部没有一个完整的依赖拓扑，而 midway 是和 spring 一样一直保存了这份拓扑，两者实现的 ioc 方式不同，没有优劣之分，

[zanminkian]

这和ioc关系不大，这里只是讨论一个框架加载模块是用静态导入还是动态扫描文件夹。打个比方，下面例子中，express是如果要使用中间件，需要导入，然后再use，express内部也完全改成扫描middlewares文件夹内的js文件，然后自动添加到中间件列表里面去，单很明显它没有这么做。

var express = require('express')
var cors = require('cors')
var app = express()
 
app.use(cors());

自动扫描文件夹然后动态导入，给我的感觉就是很黑盒（你可以说黑盒一点白盒一点没有优劣），但至少使用上不如静态导入灵活。

[waitingsong]

如果只是编译和启动阶段的遍历那么性能影响是可以接受的，我更喜欢开发维护的遍历（不用想 nestjs 那样还需要自己 @@privider 等等去添加信息）

[zanminkian]

我不关注启动时扫描文件然后框架动态导入的性能，我关注的是工程的可维护性和后续迭代。如果midway遍历文件然后动态加载（我估计是收到了古老的egg的影响），那么我需要关注midway的是如何加载的，项目并存cjs和esm的兼容性、midwya能不能支持mjs、cjs的文件后缀、如何渐进式地迁移到esm等一系列问题，而这些问题都是因为midway黑盒地实现了遍历文件然后动态加载。

如果midway不遍历文件，要求静态显式导入，那么最终只有一个启动文件，顺着这个启动文件的import语句，我可以定位到所有加载到项目的js文件，而这些加载方式是遵循node的标准的，我不需要再额外学习。如果我项目想要渐进式迁移到esm，我可以逐步将一些文件改成mjs文件后缀，最后改到所有文件都是mjs文件后缀后，再改pacakge.json的type为module。

[zanminkian]

总体来说，框架扫描文件动态加载，除了可以让开发者少些几个导入语句之外，没有其他的优点。midway如果不遍历文件，而是加载一个根启动文件，由这个启动文件导入需要的controll和provider，对midway来说还省去了很多遍历文件的逻辑，只需要加载那一个入口文件即可。

大部分人都不喜欢自己维护这种静态的加载关系

不太符合node规范的东西就不应该提倡，如果这些人喜欢，完全可以自己在启动入口文件封装一个文件遍历的函数组装midway需要的export

[waitingsong]

总体来说，框架扫描文件动态加载，除了可以让开发者少些几个导入语句之外，没有其他的优点。midway如果不遍历文件，而是加载一个根启动文件，由这个启动文件导入需要的controll和provider，对midway来说还省去了很多遍历文件的逻辑，只需要加载那一个入口文件即可。

大部分人都不喜欢自己维护这种静态的加载关系

不太符合node规范的东西就不应该提倡，如果这些人喜欢，完全可以自己在启动入口文件封装一个文件遍历的函数组装midway需要的export

要不搞个投票，看“自己维护静态加载关系”是喜欢的多还是不喜欢的多～

[zanminkian]

@waitingsong 恕我直言，这不是搞框架正确的思路😓。用户需要的能力但是 midway 不能很好提供不是搞个投票能解决的。

[zanminkian]

Midway 这种启动方式，和最近掘金大火的一片技术文章《不要再写满屏import导入啦！🔥》有点异曲同工，但是认为这篇文章一开始的出发点就是错的。用户看起来节省了点代码， 这种根据文件结构（或者装饰器注入的metadata）动态导入的方式维护成本反而可能更高。高赞评论全是骂声一片🤣

[waitingsong]

对于那篇文章，我和你观点一致：过度隐藏细节不利于团队合作以及调试维护。
对于框架级别我觉得还是自动扫描加载要方便些。

[czy88840616]

我也讨厌黑盒，所有逻辑尽可能有迹可循。（另外，前端的开发实践和 node 开发还是有很大的区别，跟性能，编译相关度没那么大，无效 import基本不存在）