一直对fis了解的模模糊糊的。通过fouber最近几篇慢慢理解fis具体在做什么了，也学到了很多少见的干货。
期待持续更新好文。

示例的链接搬错了。
今天把几篇文章详细阅读了几遍，加上前几天的面授，受益良多

@nimojs 多谢理解，后面还会有其他篇幅介绍前端工程的，敬请关注

@atian25

已修改，多谢提醒

fuck things!

点赞

👍

@fouber
请教一个问题：
我们项目使用的是PHP开发但模板引擎不是 Smarty。
这种情况如何利用fis帮助我实现检测文件修改后自动更新对应资源路径。

File "src/photo/img.jpg" changed.
Create "src/photo/img_XmsD8daS.jpg" .
Replace :
        <img src=\"src/photo/img_8sDuxSma.jpg\" > ==> <img src=\"src/photo/img_XmsD8daS.jpg\" >

        background-image:url("src/photo/img_8sDuxSma.jpg") ==> background-image:url("src/photo/img_XmsD8daS.jpg")

Update: http//static.cdn.com/src/photo/img_8sDuxSma.jpg

如何不要求后端做任何修改的情况下完成自动检测修改-复制修改资源并加上md5后缀-更新资源。

@nimojs

https://github.com/fouber/static-resource-management-system-demo
可以参考一下这个样例，有完整的运行起来的方案

@fouber
感谢指点。今天又尝试了一下 rsd。

我将FIS解决方案理解为“配置”好的FIS项目
当我对FIS的使用和了解足够深入的时候，可以利用FIS定制出最适合自己开发需求的解决方案的？

纯前端开发grunt可以完成绝大部分的工作。（前端组件，纯前端开源项目）
涉及到生成环境时候FIS可以完成很多grunt不能完成的工作。

@nimojs

你的理解非常非常正确。

前端架构大部分工作要解决的是 如何用工具连接框架和规范的问题。这是一个工程问题。fis想解决的正是规范与框架的链接问题，而不是简单的前端源码构建。

所谓框架，主要指模块化框架，其职责包括对模块化资源的管理和加载，管理包括js/css的依赖管理，加载包括按需加载和请求合并，以及资源缓存与更新。

所谓规范，主要是指开发和部署规范，比如哪些是模块化资源，哪些是非模块化资源，模块化资源如何包装、优化和部署，非模块化资源如何部署等，什么文件发布到什么目录，是否有CDN等等。

框架、规范、工具三者需要紧密配合才能比较完美的解决模块化开发、性能优化等前端工程问题。

fis本身是一种特殊的 “工具”，通过一些比较 “奇怪” 的配置设计，实现了框架与规范的绑定过程。这些问题我觉得是grunt/gulp不曾思考过的。

fis的解决方案，包括你看到的rsd，还有 scrat，其实都是对fis的配置，每一套配置用于连接一种特定的规范和框架：

• fis-plus：以smarty为模板引擎，以 mod 为模块化框架，适用于php后端渲染及部署运维方式的解决方案。
• yogurt：以swig为模板引擎，以 mod 为模块化框架，适用于nodejs后端渲染架构及部署运维方式的解决方案
• jello：以velocity为模板引擎，以 mod 为模块化框架，适用于java后端渲染架构及部署运维方式的解决方案
• pure：无后端渲染，使用前端模板，以 mod 为模块化框架，适用于纯前端，前后端严格分类的项目
• gois：go语言解决方案。
• spmx：纯前端方案，以seajs为模块化框架，一个示例项目，不完整，不要用于生产
• rsd：纯粹是为了展示静态资源md5问题的项目，把fis所有的语言插件都装上，可以在一个项目里混合多种语言进行开发，用资源内嵌实现打包，可以认为是最简易的fis，不适合大规模生产。
• scrat：以 scrat.js 为模块化框架，内含webapp、seo、olpm三种模式，其中：
  • webapp是纯前端解决方案，依赖combo服务实现资源合并，适用于中型移动端单页面应用。
  • seo是多页面模式，以swig为模板引擎，进行后端渲染，支持quickling（或者pjax），以combo服务合并资源，面向需要seo的单页面应用。
  • olpm是运营后台模板开发模式，我们内部有一个CMS，可以用这种模式进行开发，本地预览，然后把代码打包上传到cms系统，作为专题模板使用。

总之，由于前端的开发环境、开发模式、部署方式实在是太五花八门了，有传统多页面模式，有移动端SPA模式，有CMS组件化拼装模式，不同的模式还可能会结合不同的后端语言（不要以为前端可以完全从后端剥离出来，不理解其中的原理，我可以单独写一篇文章说明），所以不可能有一种固定模式能解决所有问题，fis的设计就是把所有这些模式中的公共部分抽取出来形成一个基础工具，面对不同开发部署规范、不同模块化框架再做配置即可。

所有不同的前端开发模式，有一些相同的内在联系，那就是：资源定位，资源内嵌和资源依赖这三种语言能力。这三种语言能力为什么会成为所有开发模式的共性，这和前端这种特殊的GUI软件的安装和运行方式有关，后面再另开文章讲解吧，这里就不再解释了。

@fouber 在grunt/gulp工具链中，我感觉有 yo 来做你说的“工具连接框架和规范的问题”。

@hax

在我理解，yo属于脚手架工具吧，而我说的连接主要是指：

“在开发目录中的什么文件，将来要部署到什么集群上，框架中要做哪些处理” 这样的事情，也就是连接开发规范、部署规范和模块化框架的工作。三者是需要工具进行转换的。

要实现一个完整的模块化开发体系，我觉得需要有一个工具做这些事情：

1. 对模块化资源进行扫描，获取资源依赖关系，生成依赖表，注入到模块化框架中供依赖管理、按需加载、合并请求等优化使用（资源依赖，用于连接框架）
2. 接收一种配置，标记每种类型的文件会发布到什么目录或集群中，然后扫描所有文件中的资源定位标记，将其替换成部署路径（资源定位，用于连接开发和部署规范）
3. 允许一些资源并不是通过模块化方式加载，而是直接内嵌到其他资源中使用，比如把图片以base64形式嵌入到css、js中（资源内嵌，非必须，但很有用）

以上三件事并不是yo的工作。下面图解一下这几件事：

1.所谓工具连接框架

连接框架 就是工具把静态分析的依赖关系以某种形式传递给框架，用于框架在运行时的资源管理、加载及优化

2.所谓工具连接规范（连接的是开发规范和部署规范）

给一个配置文件，告诉工具，源码中的什么文件(用reg匹配)部署后会发布到哪里(release定义)，这样，工具会把源码中所有关于这个资源的定位标记替换成部署路径。实现开发时使用工程路径，构建后使用部署路径的功能。这个功能可以保证资源的独立性，并且能对性能做优化（加md5戳）。独立性可以让资源无论是被合并、移位还是在其他地方加载都能正常运行。

@hax 很难， yo只是内置了一些grunt和脚手架， 它能做的也就是grunt能做的。
但fis实现的很多功能， 是很难用grunt这种task-base的工具去实现的， 譬如@fouber曾经举例过的资源URL替换。

不使用fis 通过其他工具能达到这样的效果嘛？

占座围观

@hehongwei44

assets pipeline?

百度有考虑用angularjs么？

@Rorchach

angularjs感觉对CRUD类产品比较合适，但百度的很多产品并非这种类型的，而且很多产品每天千万甚至几亿的访问量，如果放一个angularjs，不但每次研发部署后用户重新下载资源的性能大打折扣，而且很多业务的前端场景并不能很好的覆盖angular的功能，不能充分发挥它的价值，进一步浪费带宽。

所以，一般不太喜欢在页面上放一个几百K的，但只使用其中20%功能的前端框架，大家都恨不得量体裁衣。目前在业内能找到angular应用场景的项目，感觉大多集中在 ( pc端的 || 非核心功能的 || 后台管理系统类的 || 访问量小的 ) 页面上，我感觉百度也有团队在用，只是在一些我们没有很关注的某个页面的角落里而已。

有没有类似fis管理静态文件的开源软件。

原来是这样，技术放在大场景里要考虑这么多，这么细~
angular虽然是google的，但是现在google也没有几个产品在用，但是打算用angular替代一些主要业务。观察它的发展吧~

@hehongwei44

类似fis的专注管理前端静态资源的“软件”目前貌似没有同类，因为静态资源管理是一个结合开发框架、开发规范和部署规范的过程，并不是一个独立的软件完成的。如果提供了资源管理，绝大多数情况下要提供前/后端框架，并且定义开发规范，这是必然结果。

虽然没有独立软件，但类似的解决方案倒是有的，就是Rails的assets pipeline，相关资料：

英文版：http://guides.rubyonrails.org/asset_pipeline.html
中文版：http://guides.ruby-china.org/asset_pipeline.html

这些我在这篇blog中有提到的

grunt貌似也提供了相关的插件：http://segmentfault.com/blog/jiyinyiyong/1190000000442070

@hehongwei44

恩，只是貌似

@hehongwei44

我在这里 #5 列出了md5计算的过程，并且说明了为什么grunt这种task-based的调度控制非常难完美实现md5的原因，包括md5的递归计算、coffee/less等文件的编译之后资源定位等问题，下面也有一些讨论。

目前一直在用grunt工具处理前端资源的打包和压缩，遇到的问题确实如楼主所言的那样，停留在URL中添加版本控制。现在也在考虑MD5文件戳的方式，也一直在查找之类的工具，前段时间看到了grunt-usemin， 它对HTML的静态资源的处理很优雅，整合了常用的grunt的插件，这是典型的YO风格。今天看到rsd和fis的处理方式，确实是目前所期望的，:smiley_cat:

mark

@fouber 请教一个问题：

业务场景：
使用AJAX获取打折商品列表配合 handlebars 渲染。如果模板中需要定位CDN部署资源，如何实现？(模板也是通过AJAX获取的，不使用CSS background )

模板内容：

<!-- http://www.domain.com/tpl/goods.tpl -->
{{#list}}
<div class="box">
    <img src="/src/img/sale.jpg" alt="特价" class="sale">
    {{name}} ￥{{price}}
</div>
{{#list}}

@nimojs

把图片变成模板变量，在js中定位资源，渲染模板的时候传进去

<!-- http://www.domain.com/tpl/goods.tpl -->
{{#list}}
<div class="box">
    <img src="{{image}}" alt="特价" class="sale">
    {{name}} ￥{{price}}
</div>
{{#list}}

var tpl = __inline('tpl.handlebars');
var data = {...};
data.image = __uri('/src/img/sale.jpg');
var html = tpl(data);
console.log(html);

@nimojs 多谢理解，后面还会有其他篇幅介绍前端工程的，敬请关注

有微信或者qq吗？我有问题咨询一下你

@nimojs

把图片变成模板变量，在js中定位资源，渲染模板的时候传进去

<!-- http://www.domain.com/tpl/goods.tpl -->
{{#list}}
<div class="box">
    <img src="{{image}}" alt="特价" class="sale">
    {{name}} ￥{{price}}
</div>
{{#list}}

var tpl = __inline('tpl.handlebars');
var data = {...};
data.image = __uri('/src/img/sale.jpg');
var html = tpl(data);
console.log(html);

兄弟，能不能加一下微信，我有问题咨询

大佬现在19年底了，是不是部署方式早都日新月异了啊

请教一个问题，随着需求改动的频繁，源站上遗留的文件越来越多，如何清理废弃的css或js等文件呢？

存储不值钱，流量才花钱。一两年的 css 和 js 都还不如少几张图片的存储量大。
绝大部分情况下，有很多长尾的流量，你的静态文件是没法下线的。
不过 oss 那边也可以设置过期时间，或者定期统计流量来人工清理。

9年后，这些解决方案已经被脚手架默认支持了

9年后，这些解决方案已经被脚手架默认支持了

挖坟引起的血案，我的邮箱爆了

9年后，这些解决方案已经被脚手架默认支持了

挖坟引起的血案，我的邮箱爆了

我预感到了，我的邮箱也要被自动回复填爆了

都爆了吧

怎么取消订阅xdm……

来自联想小新pro15夜光键盘自动回复: github订阅已收到

...