fis优化梳理，持续更新，想到什么就记录什么，别关闭

[fouber]

fis配置文件在设计的时候有些配置节点语义上没有取好名字，所以导致了一些学习成本，这里做一些梳理，希望fis团队后续能针对这些现象进行一定的优化

配置节点规范

总的来说，fis的配置应该只需要4个节点：

1. system：系统配置，包括md5戳长度、连接符、编码等，就是现在的project节点，我后来觉得叫system更合理一些，把project节点留给用户使用
2. pipe：或者叫processor，流程配置，fis有内建流程，用户根据内建流程进行配置即可。取名pipe可以撘gulp的顺风车，而且语义性很强
3. plugin：流程插件的运行时配置，就是原来的settings。settings太大了，用plugin这个词会好一些。
4. file：或者就叫file_system，就是现在的roadmap.path，当初起名是从fis1继承下来的，如果叫file_system可能会更容易理解一些。把roadmap.ext、roadmap.domain都统一到一起就可以了，不用独立出来。

   开放deploy插件

将deploy阶段开放为插件实现，插件名为fis-deploy-xxx，内置fis-deploy-http（文件上传），fis-deploy-fs（磁盘写入），将来还会有fis-deploy-ftp、fis-deploy-rsync等

配置节点优化

1. 剔除deploy节点，归入到plugin配置下，比如fis-deploy-http、fis-deploy-fs对应的插件配置。
2. 剔除pack节点，归入到plugin配置下，它其实是fis-packager-map的插件配置

一份新的fis-conf.js配置可能看起来是这样的：

//系统配置：
fis.config.set('system', {
    charset : 'utf-8',
    md5Length : 10
});

//流程配置
fis.config.set('pipe', {
    postprocessor : {
        js : [ 'jswrapper', 'require-async' ]
    },
    optimizer : {
        js : 'uglify-js',
        css : 'clean-css'
    },
    deploy : {
        local : 'fs',
        remote : 'http'
    }
});

//插件配置：
fis.config.set('plugin', {
    optimizer : {
        'uglify-js' : {...},
        'clean-css' : {...}
    },
    deploy : {
        fs : {...},
        http : {...}
    }
});

//文件属性配置
fis.config.set('file', [
    {
        reg : '**.css',
        domain : 'http://a.b.c/',
        release : '/public/a'
    }
]);

这样学习成本会不会低一些？

去除自动添加同名的依赖文件功能，改成可配置，但默认是要添加的

[hefangshi]

建议还是按优化功能点开issue吧，也好和实现对应，有新的想法可以直接再开

比较赞同deploy的插件化，可以让deploy做的事情更广更专业，比如与ci交互甚至发布

[oxUnd]

还是在一处进行讨论后确定再开issues对应到具体功能吧

[qdsang]

deploy的插件化已经期待很久，太多重复不靠谱的事情需要deploy一步解决

[oxUnd]

FIS定义

跟@fouber，@hefangshi讨论对FIS做如下定义；

FIS是一个专为解决前端架构设计中有关自动化工具、模块化框架、开发规范、性能优化、代码部署、开发流程等问题的工具框架。

工具框架：可进行包装配置得到一个新的工具，这个工具可解决 自动化工具、模块化框架、开发规范、性能优化、代码部署、开发流程等问题。

大家什么意见？

[hefangshi]

FIS是专注解决前端项目中自动化工具、模块化框架、开发规范、性能优化、代码部署、开发流程等问题的解决方案构建工具

1.专为调整为专注，暗示FIS可以做的事情不仅仅是上述问题，但是FIS重点解决了这些问题，可以不需要自己扩展就能获得这些功能。专为感觉有局限。 2.前端架构设计改为前端项目，降低门槛，表示FIS囊括了各种解决方案需求，包括0配置的优化能力。 3.工具框架改为解决方案构建工具，首先是不引入新名词，工具框架需要重新解释，而构建工具的解释目前社区中还是比较流行的，解决方案的限定词提现了FIS的定制性不光在功能的扩展，而在于整套开发方案的定制。 4.中间「自动化工具、模块化框架、开发规范、性能优化、代码部署、开发流程」需要简化调整

[fouber]

@xiangshouding 提出的 前端解决方案通用框架 的总结比较接近了，但有些笼统。这里把fis的所有功能罗列一下，看看能不能在从头梳理一下：

压缩、校验、打包、md5戳、加域名、csssprite、文件监听、自动刷新、测试、发布目录、自动上传、内置服务器、数据模拟、请求模拟、获取组件、资源定位、资源内嵌、依赖声明、模块化规范、模块化框架、模块化规范、静态资源表、后端模块化、前端模块化、组件化规范、组件仓库、组件生态、插件扩展、构建流程、coffee|less|stylus|sass编译、与ci集成、roadmap.path配置、部署规范、fis包装定制。。。。

大概梳理一下，可能有这么几个分类比较重要的：

1. 自动化工具及其扩展能力
2. 综合解决各种前端开发问题的能力
3. 可以生成完整解决方案的包装能力
4. 辅助完成架构设计的能力
5. 开发流程、开发体验优化的能力

然而对于一条定义要传递5个信息确实太多了，看一下那些可以进一步合并精简的，把传递的信息控制在3条之内，然后考虑怎么概括fis的内含

[oxUnd]

roadmap.path配置确实需要梳理一下了。能否在set的时候是一个优先级的序列；比如fis-conf.js > fisp > fis，或者确定具体的接口来做这个事情。

[hefangshi]

优先级我认为是需要的

roadmap.path这种配置应该需要合并、覆盖、删除的能力

合并能力也需要粒度细到文件

比如fisp中定义了

{
    reg : /^([^\/]+)\.js$/i,
    isMod : true,
    release : '/static/$1.js'
}

同时fis-conf.js中定义了

{
    reg : /^test\.js$/i,
    release : '/test/test.js'
}

那么test.js的配置应该是

{
    isMod : true,
    release : '/test/test.js'
}

[fouber]

无法预测用户的真实意图，而且引入一个非常严重的黑盒效应，配置fis-conf.js的成本很高，比较难预计最后的结果。有覆盖、有继承、有顺序，这就特别崩溃了。

我始终觉得，类似fisp这种工具还会出现配置修改的需求的话，问题应该是fisp的规范设计有漏洞导致的。一个不完备的规范才会导致用户需要增加新的roadmap配置。

roadmap.path的这些能力开放，不会带来正收益的。

[hefangshi]

我觉得再完美的规范，也有照顾不到的项目需求，所以roadmap的配置肯定还是必要的。

如果觉得roadmap.path的配置能力过于复杂会让用户崩溃，那我的建议是提供一个最符合用户期望和最能够覆盖用户需求的扩展形式。

个人觉得roadmap.path的修改需要大部分应该还是停留在带继承的覆盖上，并且带继承的覆盖能力应该是比较符合用户期望的配置能力。同时只要拥有这种能力，也可以在必要的时候满足删除配置的能力。

[fouber]

比如fisp中定义了 ... 同时fis-conf.js中定义了 ... 那么test.js的配置应该是

这里用户的本来意图到底是是希望 test.js不要成为模块化文件，还是test.js继承fisp里面的设置，也是模块化文件 呢？单纯从设置上无法区分这两种用户意图。

我觉得再完美的规范，也有照顾不到的项目需求

不是这样的，首先要承认，不是所有的项目都适用fisp，所以fisp有一个适用范围，在这个范围内，fisp的规范 必须 是完备的。如果有人试图通过定制fisp来适应一个完全不同的项目，这是不合理的，这种情况下他需要的是另外一个跟fisp类似的工具。我们可以把现在用户扩展fisp规范的理由列出来，看看是不是fisp在它适用的项目范围内出现了规范的设计不完备情况。

如果觉得roadmap.path的配置能力过于复杂会让用户崩溃，那我的建议是提供一个最符合用户期望和最能够覆盖用户需求的扩展形式。

这个也是不太切实际的，因为开发规范、开发框架、fis插件、部署规范是彼此有影响的，这个相互作用关系微妙且复杂，无论怎么舒服的配置接口，修改规范可能导致插件的失效或者部署配置的错误，比如打包过程会受影响，这个结果是不可预期的。

---

应该正视 规范设计不完备 的问题，这是导致要在fis-conf.js修改规范的最根本原因。不要把完备规范的责任推给用户，用户在使用中要顾及的问题非常多，接口舒服了就能规避用户扩展规范从而破坏了fisp的架构的问题么？这是真正危险的问题。

总结一下，我的观点：

1. 用户并不真的想动规范，只是fisp的规范不完备，他们不得不扩展一下，如果这种需求合理，而用fisp现有规范又不能组合得到这种开发需求，那么fisp就是“在它适用的范围内出现了规范设计漏洞”
2. 用户要扩展规范，就要先了解fisp都设置过了什么，并且充分理解最终想要的规范结果。这个过程我相信真正能做到的只有fis-plus的开发团队，不管接口多么舒服，普通用户要掌握是非常困难的
3. fis-plus的规范应该定期维护和升级，要正视规范的不完备可能性。把用户需要扩展的规范理由罗列出来，看看fis-plus应该提供什么样的规范原则来组合解决问题。这个过程有点像fis本身的设计，不需要实现那么多的原则，只需要三种语言能力+资源表，在web项目上，fis的这种规范是足够完备的，不需要扩展内置语法。

[oxUnd]

FISP可以说是一种成品解决方案，即使是规范完备。如果用户知道fis.config.set('roadmap.path', {...})这种用法，就难免在自己遇到一些问题的时候不用它。比如1，2个js不需要md5（可能是用户的错误使用），或者是1，2个css不合并要合并图片等。当他第一次使用，就是会想到用roadmap.path设置；当这时候就会发现不好使了。当然如果其知道整个fisp的定制过程可能会想到默认的配置。但一般最为FISP的角度出发，可能是不会那么详细的介绍整个定制过程（介绍了估计也没人看）。所以fisp作为fis最紧密的用户，它表示很沮丧。