atool-build 后续开发计划 #241
Comments
|
兼容老版本的 roadhog ? |
|
直接用 roadhog 如何。 |
|
现在的出发点是如何兼容老的业务开发模式同时继续保持工具的发展。 直接用 roadhog 业务上应该是不行的，变更太大，现在基于 atool-build 做衍生工具的大的线就有 4 条： chair-react 、fengdie、 site、tiny 。 |
|
|
现在 -1 分支上 其实配置大都来源于 cra 我只是适配到了 webpack@2 ，这一点应该即使废弃了 -1 分支还是会继续那么做的。 优化修改 webpack.config 的体验，这一块目前想到的是把之前这部分内容按功能独立成插件，目的一是让新进开发者知道插件是干嘛用，二来能实现共享，现在很多人写了一些配置，但不知如何在业务中共享。 这一块想要在兼容目前的方式下尝试做个类似于 https://github.com/andywer/webpack-blocks |
|
@sorrycc 老版本的 roadhog 能介绍下么 |
|
无痛升级 |
|
不管怎么更新，近期建议千万保持向下兼容。现在业务方开发团队很多都在走 H5 全栈方式做，不兼容的升级会直接影响到他们的使用体验。最近很多业务还在 antd mobile 的折腾阶段，这时候经不起工具再折腾了（之前刚刚经过 spm amb atool 的折腾，已经造成不太好的影响了）。 另外题外话，atool 的初衷就是为了开放和暴露配置，一个是让工具更灵活，二是让使用者不仅仅是使用者，通过配置等更多去了解 webpack 和相关技术，而初始化成本通过 boilerplate 来解决。roadhog 现在的思路好像又回去了么？如果想要替换的话实在想不出来替换的意义在哪儿。 |
|
我指的是这个比较像 能兼容已有 atool-build 版本的现有的 roadhog 的实现。 另外，关于是否引入插件机制，可能要好好想明白。按已有的经验来看，插件机制很少能发展起来，如果到头来就我们自己在玩，那还不如和 roadhog 一样走 JSON 配置的方式。插件机制也会给工具本身的升级带来困难。 |
sorrycc/blog#15 原因写过了，看 WHY 的部分。 |
|
看过了，说实话没感受非升级不可的理由。。 |
|
同上，没有感觉到特别大的价值 |
|
同上...参见Angular团队的升级方式。 |
|
简单来说，区别是：
觉得这些没有价值? |
大家别纠结在升级上，在介绍 roadhog 时我故意没有用到升级这个词，是因为目前来说，这是两个定位不同的工具。 开发 roadhog 的初衷是为了给 dva 用户更好的使用体验，另外，我不希望每天都花时间在解决 dora-plugin-proxy、热替换、样式刷新、配置问题、windows 安装、端口问题、common 提取等等问题的咨询上。 roadhog 能为这些问题提供一站式的解决方案，并且我也能从这些问题上脱身出来。 |
|
sorrycc/roadhog#18 这个 issue 已关，无线的同学可以继续安心用 atool 。 |
|
等 webpack2 正式出来再考虑发不兼容版本吧， webpack 不变，atool-build 就没必要变 |
|
针对 ant-tool 我们的出发点是 如何兼容老的业务开发模式下同时继续保持工具创新和发展。 我开这个 issue 的原因是要大家讨论下基于我们的出发点接下来我们如何去做。 另外体验上这一块目前 ant tool 确实不够友善，这一块已经在 -1 分支上尝试去解决，接下来应该会做更多这方面的优化。 诟病的配置问题，刚刚我尝试给了一个解决方案，把之前我们配置的这部分内容按功能独立成插件，这其实和 roadhog 使用 JSON 方式本质上并没大的差异，只是更为灵活了一点，因为用户也有了创建配置的能力。这么做的目的是：1. 让新进开发者知道插件是干嘛用 （现在我碰到非常多的咨询，他们对于脚手架 init 出来的这部分内容完全无感知，导致后续自己针对构建需要独立配置时，我真的只能用灾难来形容），二来能实现插件共享（比如针对 antd 的 babel-plugin-import, 还有无线中有很多妙用，这一点能带来的受益，难以想象）。 另外云谦提到了内置组件和样式的热替换这一块其实在 dora 里面是有插件实现的。说白了其实这是因为内置的 extract 引发的，其实在开发环境中舍去即可。就不会有乱七八糟的问题。 |
|
@yiminghe webpack@2 已经 RC 了，可以做到升级 webpack 但是 atool-build 并不改变，这一点已经在 分支一里面完成，完全基于 2 同时完全覆盖了目前的所有用例，不需要改什么。但是对于基于 atool-build 去拿内置的根节点下 babel、ts、 postcss 这些参数这些就行不通了，因为在 2 里面严格规范了写法，这一点可能到时候需要第三方工具修改，或者 atool-build hack 下也行。 |
|
roadhog 和 atool-build 都包含 build 功能，如果这个2个工具提供的 build 产出物有差异，那么就会出现开发者说“我本地是好的，为何在雨燕 build 出来就坏”的尴尬场面。 roadhog 为何不能使用 atool-build 代替自己的 build？又或者说为何不能都收敛到 roadhog？ 工具不尽量收敛的话，长期下去会积累越来越多的历史包袱，再过一年又会回到 spm 的状况。 |
|
@fengmk2 不会出现你说的这个情况吧 - “我本地是好的，为何在雨燕 build 出来就坏” 雨燕只是调用了 pkg.scripts 里面 build 的内容，至于内容是什么并不做约束，目前业务项目里面还有大量使用 gulp 来组织构建流程的。
两者定位本身就不太一致，从 roadhog 本身定位出发，它是 dva 生态的一个部分，而 atool-build 则应该是包含于 roadhog 的，roadhog 是某一方向上精细的体验集合。roadhog 目前它提供了类似于 spm 时候通过配置项的方式来决定是否开启或配置某个功能，而 atool-build 则更加偏向原生 webpack 的使用方式。 从构建的根本上来说 - 即 webpack 的配置， roadhog 和 atool-build 存在差异性，但也有共性。我觉得这两者的收敛可以提供更加底层的 webpack 配置生成方式来入手，这就是目前我在做 webpack-lego 的原因。 希望之后 roadhog 和 atool-build 都基于相同的底层结构，面对自己的特殊技术选型做各自单独的体验即可。 |
|
@pigcan 为何一定要分 roadhog 和 atool-build 呢？为何不集中人力做一个？不管是 roadhog 还是 atool-build 都可以，合力做一个。而不是你们2个人一人做一个。站在开发者角度去想想你们2个人提供了2个类似的方案，然后然开发者选，他们能选择吗？ |
|
漏看前面的了。。 |
|
@fengmk2 现在基于 atool-build 和 dora 插件做二次开发的重要的业务线有好几条，800 多个项目摆在那，这个变更不是你能一刀切的，这中间 100% 存在不兼容。 另外有一票子的人不想再在工具上有任何的变更，可以尝试理解下楼上一些留言的情绪，基于现有业务向下兼容和稳定的前提下，继续创新 atool-build 是目前我能想到最好的出路，这也是我正在做的，做一个足够通用的构建底层，来打通 roadhog 和 atool-build 的底层，这后续会和云谦做更多的一些沟通，本质上最后都是基于 webpack 针对特定的定位做的不一样的封装。 至于为什么 roadhog 会存在， @sorrycc 可以把你的初衷再说一说。 |
|
初衷前面贴过了，就不重复了。我觉得就按现在的方向继续走吧，工具每次更新都有很多人有不同意见的，听取建议自己拿决定，目前来看分开是比较好的选择。 另外，感觉 roadhog 是 atool 发展到一定阶段的必然结果，暂时是合不起来的，atool 铺的面太广了，roadhog 不可能全兼容，全兼容的话就不是 roadhog 了。 |
|
迁移时可以按升级方案修改用户的配置，这样升级成本会小点。 |
|
那没有结论，内部 build 继续只使用 atool-build 好了。 |
|
结论是二者并存，不同的项目类型选用不同的。 |
|
那问题来了，什么样的项目类型选择 atool-build，什么样的项目类型选择 roadhog 呢？ |
|
不用选，跟着脚手架走。dva-cli 初始化出来用 roadhog，其余的用 atool-build 。 |
|
现有项目升级呢？如果它升级到基于 dva，该怎么改代码？ |
|
像 chair + react 的应用，到底选择哪个呢？ |
升级到 dva 只是加了个 dva 的依赖，没必要改工具。
atool-build，跟着脚手架走，脚手架就是一类项目的最佳实践。 |
|
再整理下用户什么时候用 roadhog 吧。
|
|
作为一个开发者，我来说一句吧。作为一个刚学antd的开发者来说，roadhog确实给了我极大的便利，基本上配置不用改，直接构建，一行指令后页面接就出来了，而且热更换体验非常棒，感觉比之前用webpack快了好多；其实我也一直在犹豫用roadhog好还是原来的webpack好，也问了群里的一些开发者，他们的结论就是 “roadhog好用，但是要自己加一些插件的话还是挺麻烦的”。我目前不予评价，因为项目还在初始阶段，用roadhog确实够用，后面规模上来了不知道会怎么样。不过我觉得配置这类东西对于开发者来说其实挺头疼的，基本上要摸索一阵后都ok了，后面基本上不会再去动它了。roadhog在这方面确实让人很省心，最后支持云谦大大~ |
|
@sorrycc dva版本升级，dva新版本直接生成的项目用的roadhog，项目从0.x升迁1.x，从atool-build 到roadhog，升级文档上连个像样的说明都没有，还要自己找留言，去roadhog的项目里面翻所谓的无缝升级文档，也是够了。 能看看issues么，各种版本不兼容导致的问题，dva也好，atool-build也好，第三方依赖库动不动就是半年 @pigcan atool-build升级到0.9.3，但是代码库里面连个tag都没有，webpack打包有bug，想看源码找依赖版本号都没地儿找，换了提交地址，好歹readme文档写下。 另外阿里内部倾向于各种重复造轮子么，除了KPI和个人的star数带来的那点虚荣心，能不能真正做点造福社区的事。 也是服了，这么多年了，从后端到客户端到前端都写过，就没见过JS这么分裂还妄想统一世界的社区。 太上火了，项目升级dva从0.x迁移1.x，只要是涉及到阿里的控件，没有一个兼容性不出问题的。 |
|
@helloskull 对 dva 应用用 roadhog 没有问题，体验来说会更好。 但目前 atool-build 的定位目前主要适配给纯 react 中性的应用，所以对业务级可能还是会有相关的附加配置需要配置。 在未来计划中 atool-build 会变更为一个壳，构建配置交由 npm 包托管（会有相应机制)。 |
|
@phnessu4 atool-build 确实有不少时间没有升级，一来之前投入到其他工具项目，二来想要等着 atool-build 这方面彻底重构后再发版本以确保目前业务的稳定性。 关于 tag 确实是有这个问题，目前当前的库很多人有发布权限，每个人习惯都不一样，这一块后续我会做更多把控。 感谢你的吐槽，接下来我手头其他事情没有了，将会全身心投入进来，希望之后你在构建工具层提更多自己想法，当然也可以参与进来，让构建工具变得更好用。 |
相信有些同学肯定已经关注到了 atool-build-1 分支，该分支已经在 1 个多月前开发完毕。
主要的点：
但是呢一直没有发布，因为这个方式对业务项目和基于 atool-build 做第三方工具都有相关的变动。当然变动只来源于
webpack.config.js写法变了， 举个 🌰 。但沟通下来业务同学对于我们工具层的变更已经实在疲倦，虽然从一个工具的版本来看，没有到 1.0 理论上是可以发布 breakchange 的 😅。但基于此考虑在这边欲打算 废弃 atool-build-1 分支。基于以上的目前大概想了下后续 atool-build 或者说整个 ant tool 的走向（粗粒度的）
出发点是如何兼容老的业务开发模式下同时继续保持工具创新和发展
atool-build 内置配置修改提供插件机制，把目前 hack 内置 webpack config 的方式抽到插件内，插件通过
.antoolrc文件进行注册，注册完毕后，一般配置诸如是否启用 common 可以直接在 webpack.config.js 中通过 true or false 即可。这样的方式的好处是新老业务，新老方式都能均存。atool-build 和 dora 进行整合，包装一个易用级别的 cli 工具比如 xcli 该 cli 工具中会分别内置 atool-build 的插件 以及 dora 插件。考虑 atool-build 和 dora 插件机制某种意义上的一致性，言下之意就是看起来用起来像是一个整体并不是目前分裂式的体验方式，目前想要统一通过
.antoolrc统一进行服务的注册（服务：构建配置、dora-plugin）。封装更大程度是为了 ISV，内部可以继续使用拆分的方式，但是.antoolrc方式通用通过如上的配置包抑或是插件的方式更容易做出一个可视化工具，这和目前 IDE 的去向是契合的，刚刚好 ant-tool 可以在这个层面上先践行。
The text was updated successfully, but these errors were encountered: