作为一款前端构建工具,lighting主要处理的是静态资源的编译/集成/优化/输出四个方面的内容;
和市面上的前端构建工具所不相同的是:lighting的处理不需要通过繁复的配置,一切都是约定大于配置的;在一套完整定义的目录规范之上,按照预定义的逻辑规则来处理资源/数据,以满足开发者可以透明使用的需要!
lighting开发工具在1.2版本时引入了插件体系,以更好的支持应用开发的资源处理;插件体系为lighting带来了更轻量级的最小运行结构,同时也把大量的资源处理任务拆分到了插件体系中去以获取更好的编译性能。
掌握lighting插件开发的方法,需要理清一下几个问题:
- lighting的编译流程
- 插件执行阶段
- 插件的包结构
- lighting的编译流程
lighting对开发功能的处理有四个阶段:
- 环境准备
- 资源编译
- 资源打包
- 调试运行
环境准备
在lighting1.4.1之前的版本中,工程的根目录只有3项:
- project.json,工程的配置文件
- src,源代码目录
- dist,输出代码目录
在1.4.1之后,将整个工程目录作为src,并在系统的缓存目录中创建一个此工程的缓存作为dist目录
lighting的整个编译流程中都不会对src目录做任何操作,只针对dist目录进行构建处理,所以在真正的开始构建之前,需要将全部的src目录的内容拷贝到dist目录,这也是在环境准备阶段lighting工具所完成的事情。
- 删除dist
- 拷贝src到dist
资源编译
资源编译是lighting构建的重头戏,耗费了整个构建流程80%的时间。为了方便理解,我们把资源编译阶段细分为三个过程:
- 资源预处理
- 资源构建
- 资源后处理
在前端开发领域面临的三种主要的技术,代表页面行为的JavaScript/代表页面样式的css/代表页面内容的html,这也是浏览器所能直接处理的3项内容,任何基于此内容的变种浏览器都是无法支持的,比如es6/less/jade这种自成体系的语言语法,需要通过转译成对应的JavaScript/css/html才能被浏览器真正的接受和认识。预处理阶段就是为了完成这样的事情,将不受标准支持的内容转译成可参与构建的资源,这个阶段就是为资源构建阶段准备资源的。
资源构建阶段发生的事情,就是在lighting这套目录体系之下的资源组合/资源处理,最终输出为一份可以正常运行执行的代码结构。构建阶段会根据指令参数做出不同的处理,比如-s会触发对资源构建的后缀策略处理;-u会触发对资源构建的压缩处理。
资源构建结束之后,dist目录的代码就是可以正常运行的了,可以被浏览器认可和接受。但是,也只是仅此而已,一些对资源优化的手段并可以在后处理阶段来执行以保证最终的dist目录中的资源是极致的优化后的,尤其是在真正输出生产的发布包的时候。比如:lighting-plugin-imagemin就是一个资源后处理的lighting插件。
资源打包
release的-p参数可以触发应用打包的操作,资源打包阶段就是-p参数所触发执行的。
调试运行
在开发状态下一般都会使用lighting自带的-wb参数来运行调试环境,调试运行阶段就是由-wb两个参数所代表和处理的。
插件执行阶段
在lighting编译流程的节点上就是lighting插件的执行阶段。
现阶段,对lighting插件的执行阶段主要有四个:
- prepare
- build
- packager
- serve
分别对应了lighting编译构建的四个阶段,具体的执行流程如下:
资源准备–>prepare–>资源编译–>build–>资源打包–>packager–>调试运行–>serve
let sass = require("node-sass"); |