fis相关生态还有几件事要搞好

[fouber]

fis现在的生态还有几个小问题，可以好好搞搞：

1. 给所有主要依赖第三方的插件建立ci。花点时间，把类似uglify-js、clean-css、jshint、handlebars等fis的包装插件做一个自动ci的处理，每次这些第三方插件有升级我们就跟着升级，类似fis-components的做法，这些插件的版本要 跟第三方插件的版本号保持一致 ，我们的基本插件生态才比较稳定。
2. 主力维护几个打包插件，包括文件合并、表生成、csssprite，这些插件的质量决定了我们解决方案的开发成本。
3. 实现一个完整的前端模块化框架。虽然后端框架不能统一，但前端框架似乎有统一的可能，读表，支持线下合并，动态combo，支持localstorage缓存，支持插件等功能，能在纯前端模式下使用，也能配合后端使用，这些应该都能做得到，希望这个框架可以通用所有解决方案。（mod.js还要进一步升级，获得足够的重视）
4. 模板引擎中的资源管理框架生态。这个目前还没有特别好的方案，只能针对各种语言搞搞了

总结一下：

• 工具生态：
  • 第三方依赖：CI自动发布
  • 打包插件：主力维护
• 框架生态：
  • 前端框架：设计一个最为精妙的通用加载器，主力维护
  • 后端框架：没什么好办法，各种语言搞搞

[MicroConan]

up

[oxUnd]

up

[nimoc]

动态 combo是完全利用了 fis 的静态资源表。然后实现浏览器loader 读取资源表而完成的打包方案。

另外一个主要的点是组件平台。需支持多版本共存，通过 github用户名/项目名/版本号 的目录存放组件。(一个组件肯定只会用一个版本，但是一个项目可能需要多个业务模块多版本运行)

---

这应该算是基于 fis 的一种模块化方案。并不属于 fis 的功能点，但如果fis官方能打造一个更优秀的组件生态会更好。

[nimoc]

目前在 fis 中遇到一些问题

1. fis-components 不能多版本共存，模块不允许重名，因为安装后目录结构是 components/jquery。希望是components/my-team/jquery
2. 纯前端项目打包都是 all in one
3. 缺少 fis-postprocessor-cmd，不能完成 动态combo

对前端模块化开发的一些想法

all in one 的弊端 @fouber 在 All In One的打包策略中已经阐述过了，但目前很多工具的打包方式都是 all in one 。

我目前的做法

我目前使用的是 cmd + seajs + 动态combo 的方式。目的是做到将一个页面所需的模块分三层：

base.js

这里放 seajs 和一些常用模块的 cmd 版本的代码，例如：

/*! Sea.js 3.0.1 | seajs.org/LICENSE.md */
!function(a,b){function c(a){return fu ...
/*! Seajs-combo 1.0.1 */
!function(){function a(a){var 

seajs.config({
    alias: {
      'jquery': 'jquery/1.11.2/jquery'
    }
})

// jquery 
define("jquery/1.11.2/jquery",[],function(e,t, ...
// handlebars
define("handlebars-runtime/3.0.0/dist/handlebars.runtime",[],function(e,

base.js 中是定义了常用模块的 cmd 版本。

page.index.js

这里就是一些组件的调用代码和页面的逻辑代码，例如：

seajs.use(['jquery','chartjs/1.0.1/chartjs','tip/1.4.1/tip'], function ($, Chart, Tip) {
    new Chart({
        // options
    })
    new Tip({
        // options
    })
    $('#some').on("click", function () {
        // code
    })
})

combourl

动态combo打包 /cmd/?chartjs/1.0.1/chartjs.js,tip/1.4.1/tip.js (seajs combo 根据 seajs.use()合并的url) 这里是动态combo生成的一个 combo url ，都是一些模块代码。但是不需要 combo jquery，因为在 base.js 中已经定义了 define('jquery/1.11.2/jquery')

以上三层：

1. base层 ：存放seajs 源码和一些常用模块，这些常用模块会在 seajs 运时分析不加入 combo url
2. page层： 存放组件调用代码和一些页面独有的逻辑，这一层会经常改动，但因为里面只有逻辑代码所以重新构建也不会像 all in one 那样导致要重新生成一个很大的文件。
3. combo模块层: 模块层是根据 page层使用组件在线 combo 组成的，并不会combo base.js 中定义过的模块

这样就能在一定程度上避免 all in one 粗暴的打包造成的问题。（cmd多级依赖还是需要运行时分析的，所以combo 模块层可能要发送多次HTTP请求）

希望改进的地方

fis 能生成静态资源表，那么就能分析到 page.index.js 所需的模块。那么结合 fis 在 page.index.js中生成一个模块依赖数组（fouber在他的博客中有说过这这方式）。然后给 seajs 写个插件，读取这个表。分析本地已有的 cmd 模块直接请求 combo url。这样 combo 模块层就只需要请求一次。

心中期望的组件生态

组件平台

基于components 实现一个支持多版本共存的前端组件平台（目前 fis-components 不支持多版本共存），components 中的 deps 信息不能用 jquery:~1.9.2 要直接写jquery:1.9.2 因为可能一个组件使用多个版本。（有时候一些项目业务组件需要多版本共存）

fis install my-team/[email protected]

会在本地生成目录文件

/components/my-team/tab/0.0.1/tab.js

组件书写方式

使用 commonjs 规范，利用 fis 的 __inline('a.scss') 内嵌 css 、 handlebars 等资源。强制约定构建工具必须是 fis。可以通用 commonjs规范 但是做不到组件书写方式也通用，比如 spm 内嵌 css 是用 require('./a.css') 最终构建后的代码是 import-style('body{font-size:12px;}')。并不是 var a = require('./a.css')会变成 var a = "body{font-size:12px;}" (除非所有平台都约定支持fis这种自定义的 __inline() 资源嵌入)

fis-postprocessor-cmd

能将 components 目录下的所有文件转换为 cmd 版本，然后使用上面所说的 seajs combo 方案

---

上面说的是 动态combo的方式，但也可以直接构建一个 page.index.pkg.js 文件，这里面就是所有的模块代码。 然后在页面中使用

base.js
page.index.pkg.js
page.index.js

但要考虑如何配置哪些模块是不需要打包到 pkg.js 中的，因为base.js 已经定义过了

---

最终普通开发者的使用体验是：

1. 在github开发组件利用 git tag 标识版本号
2. 使用 fis install my-team/[email protected]
3. 在 page.index.js 中直接写 seajs.use('my-team/name/0.0.1/index') 或 require('my-team/[email protected]')
4. 最终构建成 base层 、模块层、 页面逻辑层

[2betop]

@nimojs 我先回复一点，不是只有 all in one, all in one 是傻瓜式用法，但是如果自己配置了 packTo， 是已 packTo 优先的，这个是 all in one 的内容就是剩下的零碎文件了。

[nimoc]

@2betop

fis.match('/a/*.js', {
  packTo: '/static/a.js'
});

这个 packTo ？

[oxUnd]

fis3 的请到 fis3 issues 进行讨论。参杂了不好维护，谢谢！

[nimoc]

@2betop fis3 all in one packTo 已新开 issues，求指点 :smile: https://github.com/fex-team/fis3/issues/124

---

这个issues 应该可以继续讨论前端组件生态和打包的问题吧~~