下一代FIS，你最期待改进的是什么？

oxUnd commented 9 years ago

下一代的FIS，你最期待改进的是什么？

eggao commented 9 years ago

jsLike 文件中支持占位替换功能。例: /_{baseurl}/ 替换成 xxx.abc.com

BelinChung commented 9 years ago

文档

findever commented 9 years ago

文档+1，目前文档看得很雾水，虽然跟本人自身菜有一定关系。。。

cos800 commented 9 years ago

加强 fis-components 组件库的建设

qdsang commented 9 years ago

触摸板随性点点需求搞定

nwind commented 9 years ago

集成各种环境的 portable 版本，解决各种新人遇到的环境问题
更复杂的 demo，最好是可供二次开发的半成品

asoiso commented 9 years ago

1、支持设置git源，用于组件安装、初始化脚手架 fis config --set registry=https://github.com/ fis config --set registry=https://git.oschina.net/ fis config --set registry=git@bitbucket.org

2、fis init 支持初始化项目by脚手架

3、增加package manager，fis install 从github或者下载符合 component、Bower规范的模块 fis install ftlabs/fastclick

asoiso commented 9 years ago

node-pngcrush、csssprites 快点支持nodejs v0.11.x版本，nodejs稳定版为v0.10.36、还不知道v0.11.x什么时候发布稳定版，而新一代的神器都是在v0.11.x版本上开发了，切换nodejs的版本太麻烦。

2betop commented 9 years ago

@asoiso 关于组件生态这块，不知道你是否注意到了这个。https://github.com/fis-components/components

Megasu commented 9 years ago

时不时就会有人在fis官方群提问，fis的less怎么用如。寻求FIS插件的时候，比较多的回答是要求自己按着官方文档开发一个插件。 PS：（有没有把gurnt插件改成fis插件的实战教程，结合fis的文档详细解说，那样就比较高产了）

在Grunt中文网有一个聚集插件地方有个插件列表，有相应的版本和插件介绍，所有插件一目了然，再提供快速搜索，开发者就可以比较快速的找到和安装项目中需要的插件。

现在很多fis插件都是由fex官方维护的，建议参考一下grunt的插件列表，方便开发者使用。

插件列表不明显，经常是印象中有这列表，但不知道在哪里，只好到官网一个个翻，现在要找到的方法只有：辅助开发 -> 更多插件。

asoiso commented 9 years ago

@2betop，这个比较局限了.需呀专门的fis团队去维护fis-components组件库。

从github符合 component、Bower规范的模块很多，如果能直接安装，这样安装组件的范围更大，不是单独去维护一个fis-components组件库。

我现在使用duo作为包管理器，fis做构建工具，解决fis组件安装这点不足。

zjafei commented 9 years ago

不好意思我菜可不可以搞个界面啊

2betop commented 9 years ago

@asoiso https://github.com/fis-components/components 直接提交配置文件就能自动转换组件，fis install 也能直接安装其他资源，只要目标组件能够复合 commandJs 就能在 fis 中直接用，复合 amd 规范配合 amd 插件也能直接使用。

zzmmzz777 commented 9 years ago

文档好好整理一下，前后看了多次文档，又看了源码才搞明白怎么回事。
希望将构建流程异步化，支持 gulp 或者 grunt 插件。

FIS 是个很棒的工具，希望更加好：）

okoala commented 9 years ago

希望能提高--watch后的编译速度。现在改个文件就要花4~8秒来编译~~

qdsang commented 9 years ago

component、Bower、fis-components、duojs啥啥的我觉得价值都不大，不能简单实用的把实际业务需求组件化都比较扯，安装个zepto啥的要废那功夫么。

oxUnd commented 9 years ago

@qdsang 然也

lampkid commented 9 years ago

1.支持多个module可共享引用公共module的资源，如静态资源

支持一个project下多个module，一个project一个fis-conf.js配置文件。如Zend只有一个配置文件，该配置文件可配置多个module

Mrluobo commented 9 years ago

既然是开源的项目感觉光靠FEX的人精力有限，期望可以有社区性质的东西。

oxUnd commented 9 years ago

@Mrluobo 当然，现在就是向着这个方向发展的。

fouber commented 9 years ago

想了一些配置接口，记录在这里方便讨论。

fis.set(key, value)

参数
- key String
- value *
返回值
- FIS 返回fis对象，方便链式调用

以k-v的方式设置一些配置数据，可以通过fis.get(key)读取。推荐采用express的kv设置风格(有空格)，是否需要支持 多级路径 的设置，这个需要讨论一下。

fis
  .set('foo', 123);
  .set('foo bar', 456); // express的key风格
  .set('hello', { a: 1, b:2 });
// fis.set('hello.a', 3);  多级路径设置，是否支持，要慎重讨论一下。

fis.get(key)

参数
- key String
返回值
- *

获取配置数据

fis.set('foo', 456);
fis.get('foo');   // 456

fis.enable(key)

等价于 fis.set(key, true)

fis.disable(key)

等价于 fis.set(key, false)

fis.media(mode)

参数
- mode String 自定义的状态值，比如dev、prod、test等
返回值
- FIS 返回fis对象，方便链式调用

借助css的media query概念，将一些命令中的media参数与配置中的media关联起来，用于实现同一份配置文件能够支持不同模式的效果。设计的时候，要考虑media参数的改变要使用不同的编译缓存目录。media是一种非常强大的功能，可以相当于切换多种配置模式，会成为下一代fis的设计亮点之一。

fis.set('use optimize', true);
fis.media('dev').set('use optimize', false);
fis.get('use optimize');  // 执行fis release的时候，得到true；执行fis release --media dev时，得到false

fis.match(selector, properties[, important])

参数
- selectors String|RegExp glob或者正则匹配，glob要有分组等功能
- properties Object 一种kv结构的数据，用于给匹配到的文件对象赋值各种属性。属性值如果是字符串，可以通过 $数字的方式引用selector的匹配分组，或者通过 ${key}的方式引用 fis.set(key, value) 设置的配置数据。属性值不推荐是function对象，可能影响缓存的正确性。
- important Boolean 可选，用于提高优匹配的先级，类似css的!important
返回值
- FIS 返回fis对象，方便链式调用

match是目前为止fis最最核心的功能，用于匹配文件并为止分配各种属性。下一代fis的设计亮点在于匹配模式采用层叠的方式（借鉴css），极大的方便了系统的二次甚至多次扩展和定制。参数中的selectors也希望能一定程度上模仿css的文法，只是把css中用空格表示父子关系改成了用/符号而已，也希望能支持一些css中的伪类选择器，比如:not()

match方法是fis的设计核心，所以这部分，尤其是selector的语法设计是下一代项目成功与否的关键之一。主要要解决两个问题：

能像css一样好用，支持通配、父子关系（一级）、祖先和子孙关系（多级）、伪类等功能。
相比css，还需要能实现分组，这样才能在属性分配的时候引用匹配到的分组，方便配置。

注意：这里不推荐selector参数支持多个或者并列关系，因为这会给分组引用带来麻烦，导致不知道要引用哪个分组

// 设置配置数据
fis.set('plugin less', { ... }); 
fis.set('plugin clean-css', { ... });
fis.set('mini', '');
fis.media('prod').set('mini', '.mini');  // fis release --media prod的时候生效

// 匹配文件
fis.match('**.less', {
    parser: fis.plugin('less', fis.get('plugin less'))    //使用插件
    domain: 'http://example.com',
    release: '/static/$0'    // 以后我们使用$0表示整个匹配吧，很多人都没听过$&这个引用
});

fis.match('(**).(less|css)', {
    optimizer: fis.plugin('clean-css', fis.get('plugin clean-css'))
    release: '/static/$1${mini}$2'   // ``$数字``引用匹配的分组，``${key}``引用配置数据，
});

fis.media('dev').match('**.less', {
    sourceMap: true
});

以上配置，后执行的代码优先级高于先执行的，属性通过叠加的方式作用于文件对象，最终得到需要的结果。

有关fis.match接口和selector的设计和论证可能要反复几次，把已有的fis方案都回顾一下，看看能不能覆盖全面。

fis.plugin(name[, options])

参数
- name String 插件名。插件的命名规范我们要不要再讨论一下。。。
- options Object 可选，是传递给插件的配置数据
返回值
- Function 返回插件处理函数

fis.match('**.less', {
    parser: fis.plugin('less')
});

插件的配置和文件属性在职责上可能有些重叠，这里需要谨慎讨论一下。因为插件设计的时候，可能在处理文件过程中即会使用文件属性，也会使用插件配置，那么，最终这个分配该如何选择呢？这是个麻烦的问题，我们要再好好思考一下。

大家可以跟帖说一下各种情况，看看以上接口有没有不能满足的情况

hefangshi commented 9 years ago

@fouber 说一些我的看法，简单约定一下把现在的FIS称为FIS，下一代FIS称为FIS2

关于Key的设置

这里持保留态度，Express中的get set使用的场景本就不多，并且这样的能力有为了跨请求间共享属性的目的在里面。

但是在构建工具中，如果所有配置都在一个脚本内完成，这样的设置略显多余，用变量的形式可能更合适，在不需要多次使用的地方直接设置属性也会挺方便的；如果还是准备沿用FIS的配置继承模式的模式，希望用户扩展的配置可以引用原始配置的话，是会有存在的必要，但是这就要求用户要去解决方案的源码里面去寻找键值，会比较繁琐。关于解决方案配置继承的话题后面继续说。

当然set后在属性中以 ${name} 的轻度使用是很好的用法，但是把配置用这种模式来保存显得有些重了，虽然只是使用上的问题，但是会有引导作用。

fis.media

比起media的形式，直接开放command alias的能力是否更利于理解与使用？比如

fis.alias('publish', '-Dompd', 'output');

fis publish

这里是一个尚未成型的想法，FIS2如果沿用重配置轻编程的思路，那么alias会是一个不错的用法，但是如果准备以gulp like的模式去做配置的话，可能alias以及Dompd这类组合配置都没有必要了。除了社区喜好是一个考虑因素外，个人更希望保持现在的重配置轻编程的思路来延续FIS的整体体验，除非在配置表达上有致命的缺陷。

fis.match

FIS最让人诟病的应该就是解决方案中的roadmap.path会被覆盖，以及从前到后的匹配顺序，并且一个文件只能命中一个规则，之后的规则都会被忽略掉等等问题。fis.match的规则覆盖模式应该是没有太大争议的。不过API风格上我更喜欢以前 #90 提到过的一个方式。

fis.when("**.tpl")
    .standard()
    .smartyxss()
    .htmlcompress()
    .important(10)
    .dest("/template/${namespace}/$&");

当然这种方式也有一些不好的地方，比如我希望对特定的tpl关闭压缩功能的时候，配置起来就会非常蛋疼。

一些希望讨论的问题

流程固化

流程固化带来的问题严重么？不严重，FIS的固化流程可以解决95%的问题，是很好的抽象，但是剩下的5%往往是给我们带来质疑的地方，#90 里面大家的看法是流程灵活可定制会让产品线使用混乱，最后架构不好收敛，这里我想说的是

框架可以定制流程不代表解决方案就可以定制流程，有流程固化的需求可以在包含了规范的解决方案中去做。
只要有实际需求，用户不会关心你设置的锁，他只会想方设法去冲破枷锁，虽然让用户体验到了很多成就感，但是也让突破不了枷锁的用户感到沮丧，虽然不是流程上的例子，但是有一些类似案例 https://github.com/zyeeda/fis-muffin/blob/master/muffin.js#L174-L203 https://github.com/fex-team/jello/blob/master/jello.js#L76-L85

如果是仅供产品线使用的编译工具，固化流程没有什么问题，不过如果目标是开源社区，适当的灵活在我看来还是非常有必要的。

资源定位能力

资源定位能力需要的人会用的很爽，不需要的人是接触FIS的第一道坎，这是一个好用但是侵入性较高，并且非常严谨的能力。在观察gulp和grunt这类task runner他们的Web处理实现中，我发现他们很少会进行整站的绝对路径处理，而是通过让用户自己去管理文件的引用相对关系，然后使用一些不严谨的替换手段去实现一些MD5戳的功能。

因此我的想法是，在模块化的体系下，资源定位是必需品，但是在传统的js,css,images管理模式下，资源定位并不是必需品，而且我也非常希望FIS2能够很好的解决Hybird应用下的使用问题，我们应该想办法设计一种比useStandard更友好的降级手段，以不严谨的手段实现一些资源依赖、资源内嵌、资源合并的能力。

还有一些想法在内部的平台上有讨论，明天转发出来。

oxUnd commented 9 years ago

昨天跟@fouber讨论，我赞成云龙提到的配置。我也想了很多种配置方式，也看了 gulp 相关的配置。 gulp 的配置，很像 FIS 1.0 的时候，对 TASK 的使用，每个都是孤立的。

对 `key` 的设置

解决方案 - 用户配置需要这样的配置
release 里面的变量就是一个典型的例子。

fis.then

对于 @hefangshi 提出的 fis.then ，当我看到的时候，我还以为有前置task。是否叫个 fis.src 更好？

但本身 fis.then 跟其他 fis.then 有无关联，是会相互作用还是孤立的？

fis.alias

对于这个，fis.alias 有些混淆，没办法直接想到是要的效果其实是 fis.command.alias。另外，还是保留了-ocm等的全局开关，可能会跟配置有冲突，导致理解偏差。

oxUnd commented 9 years ago

我简言带过，不想写那么多专有名词。

简要功能点

流程继续固定
不支持异步
新配置
没有默认配置
至于 file:// 域的支持，可以通过插件或者可能会在核心支持

其他

工程化普及度

经常提到并且不予支持的功能

插件异步化

异步引入的是问题的复杂化，可以看看 gulp 的插件就知道了，而且我们本身需要的地方不多。
命令行给配置传参

多多少少很多人都想要这个功能，但是不允许有这样的存在，可以设定范围内传个参数，比如 deploy 结点的名字。
插件全局域和local域

local域不予支持，考虑到整个构建工具的稳定性。另外，如果是个明白懂各种系统特性的人，其还不能玩出自己的 local ?
还有其他很多，包括臆想把 FIS 弄成 task 工具的，后续整理出来。

sandmanman commented 9 years ago

首先fis真的是目前我最想用的。之前一直在找适合我的工具。我是做HTMLCSS开发的，纯静态的页面开发。1.能够引用公共模块（header,footer等等）。2.压缩。3.CSS sprites 。问题：编译后为什么路径改了（看了文档关于绝对路径的问题，没看懂），我希望我的静态文件编译后，不要因为改变了路径，然后在本地打开HTML文件后，CSS,JS就挂掉了。（是不是我太笨，不会用。）前面有人说过，文档的问题+1。还是谢谢你们这样的团队开发好用的工具。造福了我这样的人。

fouber commented 9 years ago

@hefangshi

关于key设置

key设置需要接口，字符串中需要 ${key} 引用，插件中也会需要 fis.get(key) 方式获取

关于media

fis.media(mode) 是为了让一份配置具有多种状态，跟alias无关，就算是有 fis.alias() 接口，那么怎么让不同alias下有不同的配置呢？仍然需要media接口。另外，alias的语义很不好，从给出的例子来看，这个接口应该是fis.task，那就不可避免的引导用户把fis当做task-based的工具来使用了

关于 `fis.when().xxx().oo()` 的问题

不能把属性配置变成接口调用，很多时候，规范设计需要开辟新的属性，如果都成了接口，谁来为这些接口提供扩展呢？文件的属性应该是自由增减的，如果变成接口，维护接口的升级和兼容性是非常麻烦的事。此外，你应该拿这种配置去配一下现有的解决方案，蛋疼的不是一点点，fis的最终用户是配置fis的人，如果fis的设计者自己很爽，让最终用户蛋疼，这是不合适的做法

关于流程固化

流程必须固化。你提到了 fis不固化，让解决方案固化，解决方案的定制者属于fis的目标用户，你怎么跟他们解释流程固化的策略？这会让fis的使用成本提高很多。此外，怎么进一步实现 fis不固化，解决方案固化，解决方案使用者不能修改解决方案的固化，这也是一件麻烦的事。

资源定位能力是否可关闭

用户可以选择整体关闭资源定位，相应的也需要关闭内嵌，因为内嵌结果已经不正确了，不存在 通用的不严谨资源定位方式。注意，我这里强调了通用性。这件事只要你稍微带入到真实的开发中就能想象到原因。关闭资源定位之后，无法保留内嵌能力，因为内嵌中的资源定位有这么几个问题：

如果被内嵌的是css，其中的资源定位 有可能 需要根据新文件路径进行相对路径计算。有可能 是因为，如果是css内嵌css，或者html内嵌css，那么应该修改；如果是js内嵌css，完全不知道该怎么处理。
当被内嵌的是js文件，如果是html内嵌了js，那么应该修改相对路径，如果是js内嵌js，也是 完全不知道该怎么处理
当被内嵌的是html文件，如果是html内嵌了html，可以重新计算相对关系，js内嵌html，也是完全不知道怎么处理。

只要有 完全不知道怎么处理 的情况存在，那就意味着要么关闭内嵌能力，要么提供内嵌过程中计算的扩展能力，这又将引入一个新的配置话题，整个过程你有在脑海中把整个过程完整的模拟一遍么。。。完整的思维模拟，可以避免走很多弯路，不用得到写码写到那里才发现有这些问题。

此外，关闭资源定位，保留内嵌也将影响编译缓存，因为同一份文件被不同位置引用将出现不同的内容，这就无法缓存了。

整体关闭资源定位和内嵌能力，fis将退化成跟grunt/gulp差不多的工具，有什么不妥么？这种情况下，一切问题都可以参考grunt/gulp的解决方案。

oxUnd commented 9 years ago

:+1:

atian25 commented 9 years ago

非常感谢FIS团队提供的神器。

赞同 @fouber 的提案，补充一些其他方面的需求：

FIS的目标用户应该是各团队的架构者吧？大部分情况下，他们都需要二次封装自己团队的解决方案。所以希望在FIS团队能从这个角度思考下，减轻他们这部分的工作：

增强对现有前端生态(bower, npm)的支持，通过travis自建小生态这种方式会导致远离国外社区。
- 目前社区的主流是bower，而FIS目前的倾向是自建生态，通过travis进行同步。但这样总觉得不够完美，既然都是用脚本转换，为何不同时也支持fis install中实时转换现有类库，我这里做了一个尝试： https://github.com/ng-workflow/ngfis-command-install
- 另外越来越多的类库，包括angular，jquery-plugins都开始用npm作为仓库，但在目前FIS的架构下，如果在源目录下npm install会导致FIS初始化读取文件时的速度异常慢。
对task的支持，让他们能更容易的扩展内置command和增加新command。目前的做法都是嵌入yo-generator或grunt-cli或自写commander。目前的命令插件扩展性非常之差。
增加对generator的支持，因为二次解决方案中必须有它。
插件和解决方案的生态建设，，目前基本上都是各自为战。FIS是最底层的基础，但在这之上应该还会有一层特定领域的解决方案封装，然后最顶上才是各自项目的个性化解决方案。 同时，一个团队可能同时会做几个类型的项目，如scrat就有单页面应用和服务端渲染，如何更好的融合两者？
依赖能力方面：
- 前端模板是否也可以视为跟js，css同级别的资源。
- 支持类似polyfills.io的依赖声明和加载方式？譬如在PC上加载jquery，手机端加载zepto。（这个跟云龙讨论过一种方案）
国际化，我认为FIS可以超越和替代YO。
对测试的支持，目前的那个test过程我不太理解，在FIS的编译模式下，单文件的测试几乎是不存在的，肯定是要在postpacker阶段才能执行测试吧.

oxUnd commented 9 years ago

不管是task还是generator，以前都想过，也尝试过实现yo一样的生态。但，最终还是不合时宜失败了，使用人数少，开源建设上确实缺乏经验，今年着重得建立一个健康的社区。

atian25 commented 9 years ago

@xiangshouding

FIS的目标用户应该是各团队的架构者吧？大部分情况下，他们都需要二次封装自己团队的解决方案。所以希望在FIS团队能从这个角度思考下，减轻他们这部分的工作。

已更新到上文。

oxUnd commented 9 years ago

目标用户是对的，但不知道普通用户什么时候成为架构者。

oxUnd commented 9 years ago

再次开始讨论，大家踊跃发言。

@2betop @hefangshi @zhangtao07 @fouber @tianlili

r670615769 commented 9 years ago

html的压缩在哪

oxUnd commented 9 years ago

eg:

fis.set('namespace', 'common');

//-- system settings

fis.set('server', {
    'libs': 'pc',
});

fis.set('plugin less', {
    sourceMap: true
});

fis.set('smarty', {
    left_delimiter: '{%',
    right_delimiter: '%}'
});

fis.match('/plugin/**.php', {
    release: '$&'
});

fis.media('dev').set('domain', '');
fis.media('prod').set('domain', {
    css: 'http://cdn.baidu.com/',
    image: 'http://cdn.baidu.com/',
    js: 'http://cdn.baidu.com/'
});

//-- map.json

fis.match('map.json', {
    release: '$&'
});

//-- css like file

fis.match('**.(css|scss|less)', {
    optimizer: fis.plugin('clean-css', fis.get('plugin clean-css')),
    domain: fis.get('domain').css,
    useHash: true
    //release: '/static/${namespace}/$&'
});

fis.match('**.less', {
    parser: fis.plugin('less'),
    isCssLike: true,
    ext: 'css'
});

fis.match('**.scss', {
    parser: fis.plugin('scss'),
    isCssLike: true,
    ext: 'css'
});

fis.match('/widget/**.(css|scss|less)', {
    release: '/static/${namespace}/$&'
});

fis.match('/static/(**.(css|scss|less))', {
    release: '/static/${namespace}/$1'
});

//-- js like file

fis.match('**.js', {
    optimizer: fis.plugin('uglify-js')
    domain: fis.get('domain').js,
    useHash: true
});

fis.match('/widget/**.js', {
    postprocessor: fis.plugin('jswrapper'), //isMod
    release: '/static/${namespace}/$&'
});

fis.match('/static/(**.js)', {
    release: '/static/${namespace}/$1'
});

//-- html like file

fis.match('**.tpl', {
    id: '$&',
    useMap: true,
    isHtmlLike: true,
    optimizer: [fis.plugin('smarty-xss'), fis.plugin('html-compress')],
    release: '/template/${namespace}/$&'
});

//-- image

fis.match('**.(png|gif|jpeg|jpg)', {
    optimizer: fis.plugin('png-compressor'),
    useHash: true,
    release: '/static/$&'
});

//------

fis.media('dev').match('**', {
    useOptimizer: false,
    useHash: false
});

oxUnd commented 9 years ago

deploy 融入到文件属性中，诸位感觉会不会不太习惯？

atian25 commented 9 years ago

上面的示例有deploy融入?

oxUnd commented 9 years ago

NO，没有，还没有考虑好，不过也没啥，文件属性了概念更单一一点。

leeyeh commented 9 years ago

预处理语言除了 parser，能否添加其他扩展点，比如我们有对 less 的 lint 与 preprocessor 的需求。

fouber commented 9 years ago

@leeyeh

打算把lint流程提前，首先进行lint就没有这个问题了。

parser之后，less会变成css，然后统一对css进行preprocessor

如果你需要对less做parser之前的预处理，可以再写一个parser插件，因为fis的每个阶段都支持数组形式调用插件：

var pre = function(content, file){
    // 在这里对less进行预处理，此处content还是less内容
    return content;
};
var post = function(content, file){
    // 在这里对less进行后处理，此处content已经是css文件了
    return content;
};
fis.config.set('modules.parser.less', [ pre, 'less', post ]);

leeyeh commented 9 years ago

@fouber

+1 for lint 前置。多 parser 可以解决问题（目前也是这么做的），但是 fis 既然明确地抽象了文件的 parser 阶段，那将这里的预/后处理看做 parser 是不自然的，至少我无法看文档想出这个方式。

fouber commented 9 years ago

map.json改名为manifest.json

browneyedape commented 9 years ago

很多html5 app 内嵌在移动端里，像 appcan apiclode ，但他们都使用了相对路径。新版本是否有可能支持相对路径

oxUnd commented 9 years ago

@lrn744809337 最近在讨论这个事情，有结果过来给你说；

xwenliang commented 9 years ago

@lrn744809337 我们刚好折腾了这个相对路径: fis-zoo

fouber commented 9 years ago

@xwenliang

厉害！

browneyedape commented 9 years ago

@xwenliang 拷贝了fis的内核然后重构？好大的工程

fouber commented 9 years ago

@lrn744809337

不是的，这是fis的标准扩展方式，创建一个npm包，依赖一下fis，内置一些配置，就得到了一个新工具

oxUnd commented 9 years ago

没细看，不过很不错; @xwenliang

@fouber 内核依赖的是修改过的；

yeshuangdong commented 9 years ago

这次的配置简单化是最值得期待的产品，有没成形的官方api文档？求链接熟悉下

fex-team / fis