对项目依赖的处理 #141
Description
背景
对于“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） - 可以通过 build config 中的
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
- 💬 compile node_modules #106
- 替换 babel-loader 为 esbuild-loader #136
- 第三方模块的 css 不需要 autoprefix、postcss 处理 #55 注意考虑对于非 JavaScript 内容（如 CSS）的处理逻辑