RFC：Mako 目录结构调整

[sorrycc]

背景是现在外层模块没有分层，全部放顶层，比较乱。

// general modules
+ ast
+ resolve
+ visitors
+ runtime
+ config
+ ...

// stages
+ build
+ generate
+ dev

// features & plugins
+ features
+ plugins

// utils
+ utils

备注：

• 通用模块先放外层，比如 ast、resolve 等
• 三个大的 stage，build、generate 和 dev，关联模块放到各自的 stage 里
• features 和 plugins 是两种组织代码的形式，现在大多是 plugins，会逐步往 features 里迁
• utils 应该也有个目录，thread_pool、tokio_runtime 等可以往里面放

[stormslowly]

features 和 plugins 是两种组织代码的形式，现在大多是 plugins，会逐步往 features 里迁

这个需要讨论，竞品都是有插件系统来限制代码和管理复杂度。
features 的方案更好的管理复杂度的方式还是和社区背道而驰

个人觉得，多一层 pluings 的抽象是有必要的

[stormslowly]

目前的插件 大多只用了一两个切面，并且这两个切面之间 数据共享。可以说是无状态的。
因为大部分的内容可以在 context 取到，所以插件是无状态的；
如果需要实现的 feature 的逻辑有一定的复杂度，要不就内聚到 plugin 里面去，要不就是去 context 上挂字段。
可以 review 下 Context 结构，有内部可变的都可以收敛到 插件中实现。

这部分的插件是非常鼓励保留的。

[sorrycc]

整理下我的理解，供参考。

先抛观点：插件机制可对外提供，但「对内组织」会增加复杂性，所以对内组织会倾向于去插件化。当然，插件机制有其优点，比如可插拔，但缺点可能更多一些。

为啥说会增加复杂性？

1、以下述代码为例。当阅读到 build 函数时，前者可以在一个函数体内了解所有逻辑，后者需要在多个文件之间跳转查看才能了解所有逻辑，同时还要关注 compiler 里的插件顺序。就这个场景来说，without plugin 带来的复杂度相对应该是更低的。

without plugin.

function build() {
  a.build();
  b.build();
  c.build();
}

with plugin.

// build.rs
function build() {
  applyPlugins('build');
}

// a.rs, b.rs, c.rs
register('a|b|c', { build() {});

// compiler.rs
let plugins = ['a', 'b', 'c']

2、潜在的「无限坑位」问题。当现有坑位不满足需求时，你会需要在代码里不断地挖坑（Hook）来让插件填，比如 Umi 处理 middleware 有 addBeforeMiddlewares、addMiddlewares 和 addAfterMiddlewares 三个 Hook。甚至插件里挖额外的坑位让其他插件填（Umi 的插件里也有不少）。

3、webpack 虽然功能强大，但代码难度应该是公认的。其中一点我理解是和内部组织也基于插件体系有关。

4、下图是《A Philosophy of Software Design》一书中摘录的一段，供参考。

当然，会有多个视角，比如核心开发视角、框架模块贡献者视角等。对于后者来说，可能插件更好一些，因为他不需要关注如何接入 Mako。不过这种场景，我觉得更多对于外部用户而言，在非 mako crate 里组织代码的方式。

[PeachScript]

周会讨论：

1. features 和 plugins 有争议
2. 现阶段两者并存，后续再确定重构方向