[RFC] Plugin API 完善方案

[sorrycc]

一些问题

1、基于现有的 jsApi 能否满足需求？

比如支持自定义 markdown loader，现在是不支持的。现在提供了 hooks，包含 onCompiileLess 和 onBuildComplete，没法处理通用逻辑。

2、WASM Plugin？

按我的理解。WASM 插件最终还是要通过 js api 的方式执行，所以使用 WASM 插件是 js api 执行太慢的场景下会需要，比如要做 ast 遍历或编译，同时需要 Mako 提供 rust api 时。此时需要提供一整套工具链，包括脚手架、编译、发布等流程。SWC 是这么做的。

但目前来看，我们可能还不需要用上 WASM 插件。

ACTION

1、规范化和丰富下现有插件接口。

name
order: Option<'pre' | 'post'>
config(sequential)

build_start(), parallel  
load(), first  
parse(), first  
analyze_dep(), first  
resolve(), first  
transform(), sequential  
module_parsed(), sequential  
build_end(), parallel

generate_start(), parallel  
optimize_module_graph(), sequential  
generate_module(), sequential  
generate_chunk(), sequential  
_runtime_code(), sequential  
generate_end(), parallel

watch_change(), parallel

接口命名遵循 umi 之前的 api 约定，事件加 on_ 前缀，时间结束加 _end 后缀，修改加 modify_ 前缀，顺序执行有值时返回不加前后缀。

注：ast 太大，来回传和序列化消耗太大，所以涉及 ast 相关的暂不提供 js api。

其他 ACTION：
现有的 check_ast 去掉，after_parse 可包含此功能。
现有的 before_resolve 变更为 resolve。

2、把 JSApi 封装成一个 Rust 插件。

记得 Farm 也是如此。

3、插件注册支持通过 before、after、stage 等指定顺序。

略

[PeachScript]

1. on_ 前缀在竞品中都是事件型的 hook，其执行结果不影响构建产物，建议基于这个原则重新调整下
2. 相对于 webpack 的 after，rollup 的 end 来说 complete 略长，从语义上来讲用 end 也可以？
3. 这一期的 JSApi 缺个列表
4. 没理解 JSApi 和插件注册之间的关系，是在 okam 层提供和 Umi 类似的 PluginAPI，然后继续借助 hooks 和 JSApi 连通吗

[sorrycc]

1. on_ 前缀在竞品中都是事件型的 hook，其执行结果不影响构建产物，建议基于这个原则重新调整下
2. 相对于 webpack 的 after，rollup 的 end 来说 complete 略长，从语义上来讲用 end 也可以？
3. 这一期的 JSApi 缺个列表
4. 没理解 JSApi 和插件注册之间的关系，是在 okam 层提供和 Umi 类似的 PluginAPI，然后继续借助 hooks 和 JSApi 连通吗

1、transform_js、transform_css、generate_transform_js、generate_transformcss 去掉 on 前缀 2、_complete > _end 3、JSApi 是在插件 API 的基础上，1）命名风格修改为小驼峰，2）去掉和 AST 相关的 API 4、Umi 里是否提供 PluginAPI 得看上层（Umi）自己需要插件体系，Mako 不需要不关心这件事。JSApi 和插件的关系是，Mako Rust 代码里会新增一个插件，这个插件里会加上所有插件 API 的 Hook，Hook 里调 JSApi。