【新提案】ECMAScriptParser

[Jack-Works]

https://github.com/Jack-Works/proposal-ecmascript-parser/

在我司的业务中有需要在 runtime 将文本转换到 AST 进行一些变换之后再转回源码，目前使用的是 TypeScript compiler API 但是在浏览器中处理大文件（Webpack bundle）的性能不理想。
如果 JS 能自带一个 parser API （类似 HTML 的 DOMParser 或者 CSS Houdini 的 parser API）的话，对于此类需求能够显著地提升性能。

在上面的链接中提到了一些 Use case：

1. 检查代码是否语法正确而不需要调用 new Function （会被 CSP 拦住）
2. 沙盒
3. （目前看来不太现实）扩展自定义语法，例如 JSX

上面没有提到的 Use case：

1. Babel 等工具可以尝试先使用 native parser 来解析源码，如果没有语法错误（都是当前引擎可理解的语法）就能大幅提高编译速度。

目前遇到的主要阻碍有两点

1. 没有标准化的 AST （有很多不同 flavor 比如 ESTree 或者 TS 的 AST 但它们都不是标准）
2. 引擎内部的 AST 似乎和标准中的很不一样，针对速度进行了优化（可以进入慢速的标准模式，但这需要引擎维护两套 AST，实现者肯定不愿意）

[hax]

感觉上这个东西得等到 realm 和 binast 之后比较有机会。

• 检查代码是否语法正确而不需要调用 new Function （会被 CSP 拦住）

创建 Realm 后用 realm.globalThis.eval() 似乎可以不受CSP限制？

• 沙盒

沙盒这个事情现在的realm草案应该可以涵盖了。当然现在realm草案在没有parser API的情况下，只能自己去处理parse代码的事情（如果要接管eval的话）。

• （目前看来不太现实）扩展自定义语法，例如 JSX

确实感觉比较讨厌，可定制的parser相当麻烦，要定义清楚哪些东西是可以改的。否则最后会变成从头自己写一个。

• 没有标准化的 AST （有很多不同 flavor 比如 ESTree 或者 TS 的 AST 但它们都不是标准）

感觉上，ESTree 基本上可以认为是标准，至少是可互操作的AST格式标准。

• 引擎内部的 AST 似乎和标准中的很不一样，针对速度进行了优化（可以进入慢速的标准模式，但这需要引擎维护两套 AST，实现者肯定不愿意）

我觉得这可能是一个最严重的问题，可能非常容易被引擎厂商给毙掉。理论上引擎完全可以不生成AST直接生成个bytecode啥的。

[Jack-Works]

创建 Realm 后用 realm.globalThis.eval() 似乎可以不受CSP限制？

应该吧，但是现在的 realms polyfill 还是基于 eval 实现的。

当然现在realm草案在没有parser API的情况下，只能自己去处理parse代码的事情（如果要接管eval的话）。

对，我指的就是接管 realms 的 eval，自己先按需重写代码。

[welefen]

这个感觉比较麻烦，AST 现在不统一，即使支持也有兼容性问题，到时候还需要有兜底方案。

目前使用的是 TypeScript compiler API 但是在浏览器中处理大文件（Webpack bundle）的性能不理想

把 esbuild 弄成 wasm ？

[Jack-Works]

esbuild 支持自定义 ast 变换么🤔我不是做 down level compile，需要自己写 transformer 的

[welefen]

https://github.com/evanw/esbuild 好像不支持，但 JSX 是支持的

[Jack-Works]

不能自己写 transformer 的 API 完全满足不了（我的）use case 啊

[legendecas]

@hax: 我觉得这可能是一个最严重的问题，可能非常容易被引擎厂商给毙掉。理论上引擎完全可以不生成AST直接生成个bytecode啥的。

像 JerryScript 这种面向低端 IoT 设备的 JS 引擎就没有 AST，直接 emit bytecode 的。TC39 里也有像 moddable 这样的 IoT 方面的实现者。

[Jack-Works]

的确是，那么如果允许引擎可选实现呢？

[hax]

如果是可选实现，那么像 @welefen 讲的，还是需要有兜底方案（这就增加了实用的复杂度）。那么这个提案的意义就只有：

1. 标准化的AST。
2. 在引擎实现了的时候，有更好的性能表现。（然而这一点其实可疑。）

从引擎厂商一贯尿性（以实践上站不住脚的性能理由毙掉decorator，一点点维护成本都不愿意承担而毙掉我的this arg reflection，为了简化引擎实现而准备干掉builtin subclassing……还有延宕 realms 提案等）来看，基本没有可能性。

我感觉唯一的机会还是在 binast，当有了 binast 之后，引入可操作 binast 的 api。