是否需要增强edp extension机制

[errorrik]

当前，edp extension机制比较简单：

edp extension <directory>

上面的命令将注册一个扫描目录。edp的安装目录会作为默认的扫描目录。扫描目录下的node module中，如果包含export.cli对象，则认为这是一个命令。

这种机制的优点是：

1. 简单
2. 子命令集就不用批量注册了，只要注册扫描目录，剩下的事情edp会自己搞定

缺点是：

1. 管理不便，谁也不知道哪个命令是来自哪个目录下的哪个node module
2. 如果存在重复命令，不管什么处理策略，都是有问题的

所以，是否需要增强，或重新设计edp extension机制？

@leeight @otakustay @chriswong @firede

[leeight]

edp extension的定位应该给少数一些同学使用的吧，开发自己的扩展。如果是这样子的话，是否固定死把extendsion放到$HOME/.edp/ext目录，每个目录是一个自己的cmd，这样子就不会有重名的问题了

[otakustay]

为啥不是edp extension [一个npm包名字]全部通过npm来动作呢

[errorrik]

如果是这样子的话，是否固定死把extendsion放到$HOME/.edp/ext目录，每个目录是一个自己的cmd，这样子就不会有重名的问题了

原先想法是，扩展开发者开发的是一个独立的npm package，只要npm install xxxx，edp下就自动出现相应的命令

为啥不是edp extension [一个npm包名字]全部通过npm来动作呢

现在就是通过npm来动作的。看https://github.com/ecomfe/edpx-ria/blob/master/package.json的scripts部分。不知道你说的是不是这个意思

[leeight]

如果全部通过npm来走的话，那就没必要区分extension还是core-command了，全部按照同样的逻辑来吧....

[otakustay]

我理解core-command是reserved command，预先配置在edp中的，extension不能和这个重名，否则直接拒绝，总得给官方留个活路

[otakustay]

现在就是通过npm来动作的。

和我的预想有点不同，我的想法是：

1. edp extension xxx edp-xxx
2. edp把edp-xxx安装在自己的node_modules下
3. edp-xxx必须暴露一个cli模块
4. edp xxx等于require('edp-xxx').cli(args)

这样不需要extension还要写scripts，扩展可以独立出来和edp没关联，比如我本来就是自己的一个工具，现在想接edp，只要加个cli就能用了，而原来已经装了我这工具的，update以后也不会说edp未安装不能用了

[errorrik]

我理解core-command是reserved command，预先配置在edp中的，extension不能和这个重名，否则直接拒绝，总得给官方留个活路

恩，这个同意。

不过，按 @otakustay 的想法，更深层次的子命令，如何支持？话说，总不能自己再代理、选取模块、往下发吧。

[firede]

关于名字冲突的问题，可以考虑和 npm 的 package name 结合，例如 edp-plugin-ria 的命令就是 edp ria xxxx，相当于一个命名空间。

[errorrik]

关于名字冲突的问题，可以考虑和 npm 的 package name 结合，例如 edp-plugin-ria 的命令就是 edp ria xxxx，相当于一个命名空间。

原先考虑的edpx-xxxxx就是这么来的

[otakustay]

不过，按 @otakustay 的想法，更深层次的子命令，如何支持？话说，总不能自己再代理、选取模块、往下发吧。

我理解二级子命令应该由一级子命令处理，最多我们提供一个“在线拉子命令安装并调用”这样的工具模块出来

[firede]

现在 edp 的 reserved-command 和 extension 升级成本都比较高，有些项目太久没动，在升级 edp 之后就不能用了。
我觉得版本管理问题也可以考虑一下了，比如像 grunt 这样，版本跟着项目走。

[firede]

另外，现在都走 -g 的全局安装还有个问题，-g 的模块是没有办法在项目中 require 的，他是专为 命令行工具 而生的，所以在项目的配置文件中，edpx-xxx 的引入就不够灵活，比如：

var archer = require('edpx-archer');

exports.getLocations = function () {
    return [
        // ...
        {
            location: /\.css$/,
            handler: archer.serverHandler()
        },
        // ...
    ];
};

想要这样为核心功能提供扩展就不可行了。

[otakustay]

楼上说的这问题其实就是npm link一下？

[chriswong]

扩展以 npm package name 为准，但是由 edp 提供 install 和 require 方式，这样多版本的问题比较容易处理，这样 edp 可以设定它的寻址规则，优先使用项目 node_modules 下的

[firede]

对，就是 LS 和 LSS 说的意思，项目中的 node_modules 优先~
npm link 是好方法，适合内网环境。