问题1：当ide中已经有项目处于打开状态，运行自动化脚本的 launch 失败 打开状态的图 [图片] 运行启动脚本 const automator = require('miniprogram-automator') describe('index', () => { let miniProgram let page beforeAll(async () => { miniProgram = await automator.launch({ projectPath: 'path/to/miniprogram-demo' }) page = await miniProgram.reLaunch('/page/component/index') await page.waitFor(500) }, 30000) afterAll(async () => { await miniProgram.close() }) }) 启动脚本 automator.launch实际是调用 cli auto ,这个脚本在项目打开的情况下运行结果是直接关闭项目，没有任何报错，也不重新打开，这个bug比较严重了，每次执行测试脚本，还要手动关闭所有打开的项目，耗费心智啊。 问题二：运行miniProgram.close虽然会关闭运行的项目，但 cli auto进程会一直常驻，这个么消耗资源你们（写automator的，写cli的那些人）的良心不会痛吗 以图为证，运行几次launch就常驻几个进程 [图片] 问题三：官方文档推荐使用jest，却没有明确指出 不支持并行测试 jest默认是多workers并行测试，对多个spec文件独立运行时环境，互不干扰，且spec文件的执行顺序随机，然而小程序自动化测试严重依赖IDE环境的运行时实例，必须要launch好实例才能测试UI，也就是说jest要去的各个测试单元隔离，并强行的耦合到一起了，因此，如果你写了多个spec（1个page1个spec不过分吧，大家都是写程序的，模块化思想应该具备），每个spec中获取page实例 page = await miniProgram.reLaunch('/page/path')，想测试不同page，然后最终得到是一个page实例，且是随机的，因为你根本不知道哪个会最后一个执行。这里哪个不应该是launch多个miniprogram实例，每个实例launch自己的page,互不干扰。（目前的状态性能肯定受不了，见问题四） 如果想测试多个page怎么办呢？有两个方案，1.关闭并行 maxWorkers: "1"（手动阉割性能） 。2、把所有的测试用例写到一个文件中（这是程序员该干的事吗？）。此时此刻我需要再问一句，这么阉割jest的性能，这么编写测试文件你们（推荐用jest，却不明确指出缺陷的人）的良心不会痛吗 问题四：自动化测试过分依赖IDE的界面，这个大概不算问题，但这肯定会影响测试的性能，渲染UI要消耗资源的呀，小程序IDE消耗多大的资源你们心里没点数吗？就不能搞个像无头浏览器那样，在后台运行吗？测试用例跑起来也不用人机交互，也不用人为干预，更不用人瞪着屏幕看UI变化的对不对，要UI界面干什么呢？

一定要真机测试，一定要真机测试，一定要真机测试，模拟器没有这个问题 page页面要足够长，至少三屏，或为无限刷的页面，先向下滚动一些页面，是scrollTop的值不是0，页面内触发分享，使用button，右上角胶囊均可以。 监听onPageScroll事件，发现，分享调起好友列表会触发一次onPageScroll事件，e = {scrollTop: 0} 返回或点击好友分享后会再次触发一次onPageScroll e= {scrollTop: 翻倍后的值}，此时页面已经向下滚动了。 我检测的数据： scrollTop: 0 scrollTop: 204 scrollTop: 0 scrollTop: 409 scrollTop: 0 scrollTop: 817 scrollTop: 0 scrollTop: 1635 scrollTop: 0 scrollTop: 3270 真机参数 SDKVersion2.10.0brandXiaomimodelRedmiK20PronetworkwifiplatformandroidsystemAndroid 10version7.0.10

我的电脑配置：Lenovo E480 [图片] 半年前，也就是3月份还能基本流畅的使用，编码保存，触发自动编译（编译十分耗CPU，飙到50%是家常便饭），切换浏览器，切换IDE，继续编码等，基本没有什么卡顿感，即使稍微有一些也没有什么大碍。 到如今 7月份，8月份，9月份发的几个版本，这台电脑已经带不起来了！带不起来了！！带不起来了！！！ 我想说小程序项目组的程序员都是什么货色呢？，现在硬件不值钱了也不能这么没有良心吧，性能优化不好做也不能从来不管不顾吧！！！ 你们要不要（能不能）在文档中明确标注流畅的运行你们这个IDE最低配置是什么，每个版本的更新文档也要跟着更新这个配置啊！！！！ 让没钱买新电脑的贫下中农程序狗放弃写小程序应用好了！！！！ 能小程序的的程序狗一定得是硬件发烧友才行，半年就得换最新配置的人！！ 要不然都不敢打开IDE，steam打开都不这样，要不要把小程序项目组的人都开了，让游戏那边人来做吧。 强烈谴责，强烈谴责，强烈谴责，你们敢让小龙哥看看这个吐槽吗？？？吓死你们。。。

commonjs的循环加载会导致先加载的模块导出部分结果，引发引用失败。 已经是9102年了，小程序也早已经支持了ES6语法，但模块加载却依旧使用commonjs规范。 望早日完整支持ES6规范，更符合目前流行的前端开发环境，commonjs是node的战场。 commonjs 与 ES6 模块循环加载区别 ==> JavaScript 模块的循环加载  ,负载这块开发的官方人员是不是应该直到这些区别呢（不敢妄加揣测！）

scripts 中指定自定义预处理的命令 名字说明beforeCompile编译前预处理命令beforePreview预览前预处理命令beforeUpload上传前预处理命令官方文档只有寥寥几字，如何编写脚本完全靠猜，问题是我猜了好久也没有猜对。。。。。 猜错的脚本包括： [代码]"beforeCompile"[代码][代码]: [代码][代码]"node ./bin/a.js"[代码][代码],[代码][代码]"beforeCompile"[代码][代码]: [代码][代码]"source  ./bin/a.sh"[代码][代码],[代码][代码]"beforeCompile"[代码][代码]: [代码][代码]"console.log('wwwww')"[代码][代码],[代码][代码]"beforeCompile"[代码][代码]: [代码][代码]"touch ./bin/a.js"[代码][代码],[代码] 难道这个预处理命令是个鸡肋？真怀疑其处理能力，请问哪位大神配置出来了了。 这个脚本的执行环境到底是啥？是系统的bash环境？还是小程序工具内建的执行环境（执行能力有哪些呢）？windows与ios平台是否有差异呢（windows默认没有bash执行环境，可通过开启wsl获得bash环境）？

- 当前 Bug 的表现（可附上截图） 一直卡在这个页面 [图片] [图片] [图片] 今天早上被自动更新，然后就这样了 - 预期表现

- 需求的场景描述（希望解决的问题） 需要监听页面路由的变换。在路由变化时做响应的处理 - 希望提供routeChange的相关hook，并可以利用hook的返回值，决定真正路由方向 例如（支持promise更好）：      wx.onRouteBeforeChange(({ current: {path: '', query: ''}, next: {},}) => {})      wx.onRouteAfterChange(({ current, next }) => {})