fis
fis copied to clipboard
fis relase 时,默认把项目下所有的东西都copy到output 目录下
fis.config.set('roadmap', {
path: [{
reg: /^\/views\/(.*\.html)/i,
release: 'xx/$&' //$&表示全部匹配的内容
// useStandard: false
}]
...
本这么写只想处理项目下的views/目录的,但是却把项目下面的所有东西都拷贝了一遍,这类问题如何避免???
fis本身设计的时候,是希望工程目录是纯粹的工程资源,没有“不需要发布却混在项目中的资源”。所以一般fis的正确用法是独立创建一个工程,然后用fis release -d xxx把项目构建之后再发布到其他目录下进行部署。如果做不到分离前端工程,一定要和其他资源混在一起的话,可以配置:
fis.config.set('project.include', 'views/**');
让fis只读取views目录下的文件。 另外,roadmap.path配置的配规则并不是告诉fis去抓取这个文件,而是告诉fis所有工程文件中,服从这个reg匹配的文件对象应该标记哪些属性。所以配置了roadmap.path并不能影响fis对项目文件的读取,因为这个配置并不是定义了fis读取文件的过程。而是定义了读取到的所有文件对象要做什么分类。
谢谢,我是这么做的,但是我只想用FIS解决某些问题(对模版文件或者static下的文件md5化),因为这个功能很强大;但是这样做引发的问题却不少了。
- 使用FIS时,对于项目下的一半文件或者目录我不需要copy到ouput,只想处理某些文件,所以就会造成我的include 或者exclude正则要写的非常的长——这对后期的开发者来说是很难识别和维护的;
- 使用node的同学都知道,当我使用app.use('/st', express.stattic('./static'))改变静态目录的前缀后,在xx.html 中是这么引用资源的<link rel="stylesheet" href="/st/js/main.js">,这个时候如果配置了静资源发布规则,如: { reg: /static/(.*.js)/, useHash: true, release: '/st/$1', useDomain: true, url: '/st/$1' } main.js变成main-ddvdf23.js 期待xx.html 中 出现<link rel="stylesheet" href="/st/js/main-ddvdf23.js"> 但是模版xx.html中的引用规则却没有生效,因为FIS找不到st/js/main.js这个本地路径?感觉FIS应该着设置一个path alias,类似requirejs 改变引用规则一样; 出现st 取代 static的原因时是本地开发,出现静态目录被重新配置,这种问题也是常见的,总不能改回来吧 针对此类问题,非常捉急啊,感觉FIS瞬间不友好了?
@jackiealex
首先,fis的用法上确实不同于其他工具。
关于问题1
fis的设计概念是这样的:
fis是一个前端构建工具,我们强烈建议用户只针对前端代码进行构建。
基于这个原则,假设你有一个nodejs的项目,目录大概是:
site
├─ public
│ ├─ css
│ ├─ img
│ ├─ js
│ └─ index.html
├─ views
├─ package.json
├─ fis-conf.js
└─ app.js
经过npm安装,得到了这样的结果:
site
├─ node_modules
├─ public
│ ├─ css
│ ├─ img
│ ├─ js
│ └─ index.html
├─ views
├─ package.json
├─ fis-conf.js
└─ app.js
然后感觉疑惑,在site目录下进行fis release,fis把那些不需要的都发布了,这样很难受啊!
然而,fis本意并非如此,fis强烈建议用户将前端代码从混乱中分离出来。以上述情况为例,fis希望用户这样使用:
project
├─ site
│ ├─ node_modules
│ ├─ public # 空目录
│ ├─ views
│ ├─ package.json
│ └─ app.js
└─ static
├─ js
├─ css
├─ img
├─ index.html
└─ fis-conf.js
把一个项目拆成了前端和后端两个项目,通过在 static
目录下执行 fis release -d ../site/public
把前端项目构建之后发布到后端容器的静态资源目录里来开发和调试以及部署。
平时开发的流程为:
- cd 到
static
目录,执行fis release -wLd ../site/public
对前端项目进行持续的构建 - cd 到
site
目录,执行node app.js
启动服务器,浏览项目
项目部署的操作为:
git clone project
cd project/static
fis release -Doumpd ../site/public # 加域名+压缩+md5戳+打包+发布到site/public
cd ../site
tar zcvf site.tar.gz *
这样,我们分离了前后端代码,项目目录很干净整洁,这就是fis的设计初衷。反过来想想,如果把前后端代码混在一起,就算fis支持各种 排除
的功能,最后发布要怎么搞呢?前后端代码混在一起,fis构建的时候如果只把其中的前端代码分离发布出来了,后端的代码接下来要经过怎样的加工才能和前端部署在一起呢?有点类似:
前后端混合工程,经
fis release -d xxx
分离出前端代码,接下来还要再把这个前后端混合中的后端分离出来也发布到xxx,才能得到最终用于上线的完整代码
这样的过程不是更加“奇怪”?
@jackiealex
关于问题2
如果做了上面解答问题1的处理,那么问题2自然也就没有了。但我还是要解答问题2中你对fis的一些理解和fis设计初始上的不一致的问题。
这里涉及到fis的第二个设计原则:
解耦工程和部署,用最自然的方式写码。
举个例子,你说设置了静态资源发布规则,把static目录下的代码,都发布到了st目录下。然后试图在代码中这样引用资源:
<link rel="stylesheet" href="/st/js/main.js">
并发现fis不予处理路径。
这是因为,你的资源路径,写成了部署路径,而不是工程路径。
fis一直希望用户无论何时写的都是工程路径,这个例子中,很明显你的路径应该是:
<link rel="stylesheet" href="/static/js/main.js">
static目录才是你工程里存在的。fis识别到一个路径的时候,会用这个路径直接找到具体的项目文件,然后通过匹配roadmap.path来判断应该把原来的位置替换成什么url,这是因为fis参考了其他语言的设计思路,在源码中提供工程引用
,构建后替换为部署引用
。
这样也同时做到了解耦开发和部署的关系。将来你们的部署怎么改变,只要修改fis的配置就好了,代码不用动,fis会给你做好所有的路径转换。也不用在开发的时候还要在脑海中想象一个文件部署后地址是什么,多费劲啊。
另外,源码中的路径引用也可以使用相对路径,假设写上面那句link标签的html也在static目录下,那么代码就可以写成:
<link rel="stylesheet" href="js/main.js">
而最终构建的结果就如你所愿的变成了:
<link rel="stylesheet" href="/st/js/main-ddvdf23.js">
赞,瓶神真能码字
看 issues 才算了解fis,赞!
@lovefishs 经常上来看看啊
@xiangshouding 看了fis的开发目录的设计说明,真的很赞,建议置顶说明,官网我好像没看见。 另外我想问下用fis的这套架构思想,是不是不需要用bower了,如果能配合使用bower,怎么处理bower_components下面的文件引用关系呢?
@fouber 请教一个问题,如果按照上面的文件夹组织形式,那views里面的html里面的script link标签引用的js和css不是没有加上md5后缀吗?
@dcy
views里的html中资源引用是会加上md5戳啊
搜这个问题搜到这么老的issue。 比如我项目中的JS库 放到了,js/lib下,配置了合并为public.js,然后使用插件替换了HTML中的引用。 但是,fis依然会把,js/lib下所有的js全部copy到output下边