Open nighca opened 3 years ago
关于
社区基本已经达成一致:Library 自己只需要提供合乎最新(ECMAScript)规范的代码,由具体项目(或者叫应用开发者 application developer)去做 transpile 到 target browsers(或者其他 runtime)的事情
补充
直接 publish 源码确实很爽,用 swc 编译也很快的样子
@doxiaodong 要是能直接 publish ts 代码更爽,swc 作者最近在用 go 重写 tsc 了.. https://kdy1.dev/posts/2022/1/tsc-go
@doxiaodong 要是能直接 publish ts 代码更爽,swc 作者最近在用 go 重写 tsc 了.. https://kdy1.dev/posts/2022/1/tsc-go
确实能直接 publish ts, 反正都 ignore 类型的,赶紧 goplus 造起来
赶紧 goplus 造起来
这个难..去给这个作者安利下
你不是贡献者么,这波顶上去,作者亲和度+90%
🤣我是打酱油的
背景
对于“JavaScript Library 是不是应该在 publish 前做 transpile 的事情(为了支持在不同的运行环境下运行)”这个问题,如果不考虑现状,只考虑最终的合理性,社区基本已经达成一致:Library 自己只需要提供合乎最新(ECMAScript)规范的代码,由具体项目(或者叫应用开发者 application developer)去做 transpile 到 target browsers(或者其他 runtime)的事情
关于这个结论,详见 https://babeljs.io/blog/2018/06/26/on-consuming-and-publishing-es2015+-packages
跟随这个结论,builder 应该调整默认的对于
node_modules/
中内容的 transpile 策略;目前 builder 的做法是:node_modules/
中的 JavaScript 内容做处理(使用 babel)optimization.transformDeps
来指定需要被处理的包这里的处理指目的为运行环境兼容性的 transpile 过程,相关 PR: #109
合理的状态应该是:默认对
node_modules/
中的内容进行处理,在处理中可能会因为某 library 提供的版本已经可以满足项目的目标运行环境的需求从而可以省略处理过程达到这个目的目前来看还有两个前置问题需要解决:
package 如何标识自己提供的、区别于原有的
main
的内容这个问题上边的文章在 Recommendations to Discuss 中提到,目前来看还缺乏进展:webpack、rollup 等都没有提供对于文中提到的
main-es
/es
定位的 package.json 字段的支持注意无脑地对已有的
main
对应的内容进行 transpile 可能是不安全的,一方面转换过程可能会发生一些错误(详见 #109 ),另外一方面main
的内容可能是假设自己是一个script
而不是module
(它们对于运行环境的假设是不同的,因此可能会导致运行时的错误,上边 babel 的文章对此有较为详细的说明)对全量依赖进行处理,在性能上是不是可以接受
这个问题文章里没有提到,不过这个问题的解决也可以不依赖于 babel,而是通过引入如 esbuild、swc 等工具;不过这些工具是不是能比较好地覆盖目前 babel 提供的能力(尤其是像 babel-preset-env 这样的能力),还不太确定
builder 需要做的事情
在这俩问题都得到比较成熟的解决后调整 builder 的处理策略
P.S. 现有的
optimization.transformDeps
这样的配置项可能就需要废弃了builder 相关 issue
106
136
55 注意考虑对于非 JavaScript 内容(如 CSS)的处理逻辑
其他相关讨论