大喵
https://github.com/Tencent/omi/tree/master/packages/omix-ts - 比对了下提交记录和文本内容，发现 `omix-ts` 要落后一些，某些 `omix` 中修复的bug没有同步到`omix-ts ` - `omix-ts`中的类型定义过少，除了 `create.ts` 有定义以外， 其它几个文件几乎不存在定义，拷贝到项目中过不了类型校验。另外建议使用微信官方提供的d.ts定义文件,[miniprogram-api-typings] - 建议更新npm包 综上所述： 最稳妥且减少工作量的方法是不提供单独的 `omix-ts`, 仅需将 `omix` 发布到npm上，同时为js暴露出来的几个函数提供ts类型定义就行了
Output log information supports internationalization
我给 `component` options里扩展了一个属性选项computed,我需要给它编写类型定义, 场景: ``` Component({ computed: { sum(data) { return 1; } } }); ``` 但是发现并没有提供相关扩展: https://github.com/wechat-miniprogram/api-typings/blob/c7fb54c1274f2827aa7852071a4a1813aa9fcea2/types/wx/lib.wx.component.d.ts#L47 但是Page是提供了`CustomOption`来方便用户进行自定义属性值或者函数扩展的: https://github.com/wechat-miniprogram/api-typings/blob/c7fb54c1274f2827aa7852071a4a1813aa9fcea2/types/wx/lib.wx.page.d.ts#L39 希望能和Page一样提供一下自定义扩展类型
In SPA(Single Page Application), I add a event in page A,such as: ```javascript device.onChangeOrientation(newOrientation => { console.log(`New orientation is ${newOrientation}`) }) ``` when I leave page A to page B,...
**这个 PR 做了什么?** (简要描述所做更改) 去年的PR实现了从0到1，经过一年的项目沉淀和反馈，此次更新以灵活性、输入输出规范统一为特点 ## 功能特性 - `Taro` 插件参数支持传入函数体，并应用到了`@taro/plugin-mini-ci` 插件 之前Taro插件做了强验证，只支持传入对象作为参数，新增了支持传入函数作为参数，更加灵活。 举个例子，比如“构建微信小程序时根据`jenkins`注入的构建号动态分配机器人编号”这个需求 - 支持独立的 `open`、`preview`、`upload` 命令，操作自定义目录 适用于将`taro`作为项目一部分（混合开发）的开发场景 - 重新联调了各个平台的`CI`，一年过去了，各大平台的`CI`包都有不同程度的更新（特别是头条、支付宝） - 新增 钉钉 小程序`CI` - 统一所有平台CI构建后的输出数据，并将数据传递给新增的`onPreviewComplete`、`onUploadComplete`两个钩子 用户可以编写新的插件，基于这个钩子实现 `飞书`、`钉钉` 的 `CI`...
配置优化
主要更新了下面几点： - 页面config放入vue文件中 - 对外暴露megalo.config.js - 加入eslint - 混淆压缩支持es6 - 配置插件化 https://github.com/megalojs/megalo-cli-service
测试环境： windows 10 x64 node版本：10.16.3 试用了下瘦身工具，大概存在以下几个问题： 1. 安装阶段报错  这问题不大，我直接把代码clone下来继续跑(后续确定这个问题是node版本引起的，安装最新版本的node即可解决) 2. 如果项目中用到了递归组件，会堆栈溢出，比如我用到的[解析html的小程序插件](https://jin-yufeng.github.io/Parser/#/)，因为插件里存在自己引用自己作为组件的情况  这问题也不大，我可以先暂时把这个组件删除掉 3.如果项目中引用了第三方小程序库，用了自带的构建npm,例如 [vant-weapp](https://youzan.github.io/vant-weapp/#/),在分析页面的时候会出错：  到这里我没有办法继续往下走了，除非自己查找Bug修复它 总体而言，这个库还达不到生产要求（因为它被放在了小程序的文档里，默认而言应该是比较稳定的，起码能用），我看项目里的测试项目太过于简单和理想化了,对于大部分用户而言，我猜第一步就让Ta们望而却步了