clark-t
clark-t
这个能具体给个复现的办法吗？
您可以直接使用 input 配合 mip-data 完成相应功能
@yenshih 考虑下目前这条校验规则是否合理？至少在 MIP 数据传递和交互机制上是能够走的通的。 我理解原先的意图是使用 input 是为了发请求而 MIP 本身是没有提供类似于 MIP.fetch 的全局方法，所以得强制使用 mip-form 定义发送请求的 url 地址？ 但假如 input 纯粹是作为当前页面的某个交互元素的话，在外面套用 mip-form 就显得有点多余了
整体思路差不多，但是 utils 感觉没必要拆成包吧，直接跟着 CLI 一起升级感觉就可以了
## CLI 支持的指令 我觉得 CLI 可以分成 core 和 功能插件两部分，core 负责命令行的解析和插件调度，并且提供： ```shell # 安装插件 mip2 install xxx # 卸载插件 mip2 remove xxx # 升级插件 mip2 update xxx/all # 打印当前已安装的插件列表，可打印插件名和当前插件版本号、是否存在最新版等信息 mip2 list...
# DEV 功能升级 ## 增量编译 目前 mip2 dev 只提供了全量编译的功能，目前开发的组件越来越多，在初始启动的时候会变得有些慢了，所以需要支持组件在 dev 模式下的增量编译。即通过 server 访问到对应组件的时候再将其添加到 webpack 的 entry 中进行编译； ## proxy 机制 目前 dev 的 proxy 只是基于源码替换 URL 的 proxy，应该升级成真正的 proxy，从目前的反馈来看，通过 proxy...
VALIDATE 功能升级 #449
dev 可以集成自己的 a b c 命令，也可以外部插件扩展 sf，我的意思是这样子的，就跟 CLI 允许内置插件和扩展插件一样，可以增加插件灵活性
经讨论，明确了几个问题： ## 插件复用机制 每个插件模块对外暴露的是一个对象，对象的接口格式由 CLI 或者一个公用的 utils 包来进行统一；插件以依赖的形式去调用其他插件，而不是以 MIP2.require('xxx') 的方式去管理，CLI 只负责命令解析和插件调度、插件升级卸载等等； ## 插件不强依赖 CLI 插件统一对外暴露的对象里面必须提供的 run 方法用于接收参数，并且插件的功能是完整的，不依赖 CLI 提供任何功能，因此可以直接通过 `const plugin = require('xxx') ;` `plugin.run({xxx})` 的方式进行具体功能的直接使用
为避免命名上的冲突，我觉得 cli-plugins-utils 应该命名为 cli-utils 会比较好点，npm 包名为 mip-cli-utils; utils 除了提供公用方法之外，还提供 TS 的类型定义之类，统一约束 CLI 插件对外暴露的格式； 插件我认为应该对外暴露的是一个对象而不是方法： ```js { command, run({/* 参数 */}), /* api */ /* hooks */ } ``` 其中 plugins.run({/*...