Open longyiyiyu opened 9 years ago
fis模块内部有许多开关,但是并没有提供出来,譬如cache开关,譬如log,至少在文档上面没找到参数开关。cache开关真的很必要,因为在开发fis插件的时候,调试就得跑一个项目,如果用了cache,每次重跑都要修改一下源代码,蛋疼。
$ fis release -h
Usage: release [options]
Options:
-h, --help output usage information
-d, --dest <names> release output destination
-m, --md5 [level] md5 release option
-D, --domains add domain name
-l, --lint with lint
-t, --test with unit testing
-o, --optimize with optimizing
-p, --pack with package
-w, --watch monitor the changes of project
-L, --live automatically reload your browser
-c, --clean clean compile cache
-r, --root <path> set project root
-f, --file <filename> set fis-conf file
-u, --unique use unique compile caching
--verbose enable verbose output
其中明确有
fis release --clean
来清理缓存的命令。
对fis.compile的一点吐槽,有点复杂 ...
来个例子
https://github.com/fex-team/fis-spriter-csssprites/blob/master/libs/image.js#L125-L127
END
fis采用了与grunt完全不同的构建流程,所以:
在打包阶段你可能还需要对一些新创建的文件进行一定的内容处理,那就调用fis.compile就可以了,调用的方式是:
var file = fis.file(path);
fis.setContent(xxx);
fis.compile(file);
注意,由于新创建的文件并不是一个真实存在的文件,所以以上的代码最终走到的逻辑分支是 这里
另外,我也想吐槽:
你这只见吐槽没见原始需求,让人怎么判断对错啊。当你觉得一个系统难用的时候,有没有考虑过另外一种情况,就是你没有按照它的设计初衷去实现你的需求,而是先入为主的判断它的逻辑,然后发现逻辑与预期不符就硬着头皮hack下去,这是不是也不合理啊。。。
所以,希望你贴出你的原始需求,我来说一下fis的设计下改怎么实现,然后顺便解释一下设计思想,你看怎么样
我想的是不通过fis release命令参数去设置,而是可以在类似配置之类的,譬如fis.config.set('project.clear', false);这样。而且即使是fis release也没有完全开放所有的配置吧
@longyiyu roadmap.path 这块是否有看到过。确实我们的文档未偏向插件开发者弄,后续这块会有所增强;
第二点和需求是一点关系都没有的,提到只是为了解释方便而已,再者需求各种各样,情况万千变化,API有着时刻完善的使命但也不能肩负面面俱到的责任,既然如此,那就需要很好的文档加以说明!
如题只是吐槽,而且不是针对fis团队的,所以你们是可以忽略的
不过有一点,请在插件开发API那里,给fis.compile添加一些解释,注明使用方法,并且只能对新创建文件进行compile,不能对已存在的文件进行compile!
文档一点说明没有,直接误导开发者,所以开发者情绪不满上来吐槽一下,请别见怪~ 也算一点建议哈
PS:如果不是喜欢fis,我都懒得来吐槽的,所以我还是很支持你们的,加油!
roadmap.path不是针对文件的么,一些全局性的开关是应该放到project的吧?
@longyiyiyu 好,大家都加油;
@xiangshouding
shouding君赶紧把文档完善下,功德无量 =。= http://fis.baidu.com/docs/api/dev.html
@chyingp OK,卡卡,一起啊
https://github.com/fex-team/fis-site/blob/master/docs/api/dev.md
最近在开发fis插件,遇到一些问题,抛一下:
造成这个问题的原因有很点复杂,我理一下,先大致说我的需求: 在处理文件A时,想动态透明地对文件B,文件C的内容进行增删后处理。
首先,compile过程是针对单文件的,它完全独立,这个思想也不能说它有问题,所以不抱怨,这里需要关联其他文件,所以插件选用prepackage插入点(我能抱怨我一开始选用preprocessor时发现想关联其他文件基本不可能么?)。
选用prepackage有一个问题,就是这里的资源都是已经compile过的了,修改内容就很难了。这里很自然地就想到修改源代码,然后再手动compile一下,最后替换掉resourceMap就好了,多美好~ 文档里面也明文写好可以使用fis.compile,太简单了。
说到这里,需要深入一下fis-kernel的代码,看了release的代码,发现fis.compile需要一个file对象,于是,代码处理如下:
然后发现没有效果,最后出来还是原来的内容,找了一晚上,以为是resourceMap关联问题,以为是cache问题,以为是newContent的问题,以为是插件其他问题,就是没想过fis.compile不能用!这里我必须狠狠地吐槽一下!
直接看fis.compile的源码,useCache的那一段忽略,缓存没什么好看的,只要知道想不用缓存的时候,只要设置一下file.useCache=false即可。关键在于下面几句(可查源码):
为什么不能用?why? file作为文件的抽象,这能力也太弱了吧。去看file的代码和处理,会发现它主要只有两个作用:
好,我们不讨论设计理念问题,我再说一下这样带来的问题,现在我想要compile一个文件,我必须修改src/下面的源代码,基于src/下面应该全是源码的理念,工具的修改是不应该改动src的,但是为了解决问题,我打算先修改src,然后compile,最后再还原,这总可以了吧。
好,去构建,然后就悲剧地死循环,因为watch,后面不解释,点点点
一条路死了,我们换一条,既然compile必须基于文件系统的文件内容,那我们可以用缓存文件,复制一份src的代码到tmp/下面,然后试试,你会发现,因为file的id是基于路径的,然后各种路径关联问题,最后满头黑线,再也不想用缓存文件啦!
综上所述,fis.compile的使用路径死循环了:
整了一晚上,掉进一个设计理念的坑里,我不服! grunt系没有file抽象,都是直接读取文件系统的内容,路径关联的自由度极高,所以基本不会有这些蛋疼的问题。 但是,既然fis整了一个file抽象,路径关联也是基于file的基础上,那为什么不是所有操作都是基于file?为什么compile是必须基于文件系统的文件内容? 我以不稳定的情绪上来吐槽,不是针对fis和fis团队,只为发泄,我想吼一句,这设计真是渣。
如果compile可以基于file._content,比如以下写法:
仅仅只是一个小小地判断,但却是完全不同的两个设计理念,怎么就能差那么远呢? ps:如果想说md5是基于文件内容的话(实际上现在的实现是这样),这问题也不难解决,不赘述
当任何操作都是基于file抽象的时候,我们就可以手动创建虚拟文件file加入到构建过程中,然后做更多的事情,只要你有足够的想象力。
最后,给出我的最终解决方案,在不修改fis-kernel的前提下,在源头做了hack:
直接hack fis的读取文件系统内容的api,自己做了一层文件内容虚拟层 虽然看起来解决方案很简单,但是不到万不得已,谁想hack!