1前端工程化解决方案

模块加载器与构建工具双剑合璧,达到前端工程化解决方案的最优解。

  • 前端模块加载器(coolie.js)服务于前端页面,与构建结果深度契合,甚至在未来 es6 模块化方案成熟之后,都可以一键切换。
  • 前端开发构建工具(coolie-cli)服务于构建方面,与模块加载器深度契合,保证通用的构建前提下,又可以通过中间件来扩展构建过程。

2与后端语言无关

coolie 的前端工程解决方案只与前端有关,与后端语言无关,无论是 JAVA、NodeJS,还是纯静态站点,都是适用的。

当然,如果你的资源是通过后端语言来管理,那 coolie 肯定没法插手。

3与工程类型无关

coolie 属于通用级别的前端工程化解决方案,与工程类型无关,无论是传统的企业站,还是展示类型的营销站,还是新潮的单页面应用,还是桌面网站,还是移动网站,还是 webapp,都是可以胜任的。只要你写的代码是 html、js、css。

4前端模块加载器零配置

前端模块加载器只有少量配置项(模块加载器配置)。并且该配置文件可以自动生成(使用coolie init -j)。

5前端开发构建工具少配置

同样,前端开发构建工具的配置也是非常的少(前端构建工具配置)。也同样,该配置文件可以自动生成(使用coolie init -c)。

仅仅需要一点点配置,就可以省去你的大量的 grunt、gulp、webpack 代码。

6开发兼容 CJS 和 CMD,生产 CMD

开发环境(构建之前)兼容 CJS 和 CMD 规范(模块规范):

  1. require('./path/to/some/module')
  2. require('some-node-module');

  1. define(function(require, exports, module){
  2. require('./path/to/some/module')
  3. });

生产环境(构建之后)依然是 CMD 规范。

  1. define("0",["1"],function(r,e,m){r("1")});

7独一无二的模块路径压缩技术

上一点,构建之后的模块ID和引用ID,都被压缩成单个字符,这是其他模块构建工具无法做到的。

在这种情况下,你的模块路径可以写成任意长度,都可以在构建之后得到压缩。因此也不需要别名这些配置,既减少了配置,也方便了书写。

coolie 优势 - 图1

8资源版本管理

coolie 会对标准的资源属性引用的资源进行版本管理,即:

  • imgvideoaudioembedsourcesrc 属性
  • linkhref 属性
  • objectdata 属性
  • sourcesrcset 属性
    构建前后对比:
  1. <img src="/path/to/img.png">
  2. =>
  3. <img src="http://cdn.org/res/file_md5_version.png">

file_md5_version表示文件的 md5 版本号,下同。

9资源分组管理

有资源分组管理,就更好的执行 css 模块化了。

  1. <!--coolie-->
  2. <link rel="stylesheet" href="normalize.css">
  3. <link rel="stylesheet" href="base.css">
  4. <link rel="stylesheet" href="text.css">
  5. <link rel="stylesheet" href="button.css">
  6. <!--/coolie-->
  7. =>
  8. <link rel="stylesheet" href="http://cdn.org/res/file_content_md5_version.css">

在书写 css 的时候,只需要按照模块类型分开写 css,然后再页面上按需引用即可。

同样的,js 也是一样的,这里推荐直接使用 cmd 模块化方案。

智能的 coolie 在处理同样的分组不会再次合并,会将上一次处理结果缓存下来。

10支持模块分块构建

默认情况下,一个模块入口会将所有被依赖的模块打包成一个文件。当我们的工程里大量使用了相同的模块的时候,我们就应该考虑将这些公共模块单独独立出来,这就是模块分块构建策略(详细点这里)。

11支持异步模块构建

有些模块是不需要在页面初始化进行载入的,这些模块只在特定条件才会被使用,那么这些模块适合写成异步模块,比如单页面应用就非常适合。

coolie 优势 - 图2

12自由扩展,私人定制

coolie 在 1.x 版本之后已经支持扩展支持了(使用 coolie 中间件)。通过 coolie 中间件可以完成你的个性化需求,实现私人定制。

13长期维护,中英社区支持

coolie 定位于通用级的前端工程化解决方案,将会长期发展下去。

coolie 的相关问题、建议、意见可以在中英社区里提出:

14代码开源,安全保障

15企业产品,质量保障

目前 coolie 相关东西已在企业级产品中得到广泛使用。

16鹤立鸡群,傲视天下

目前,开源的工具中,没有任何一款工具与 coolie 相媲美。coolie 所做的事情,虽然普通,但却意义非凡。在类似功能的产品中,如 grunt、gulp、webpack、postCSS 等,都需要人为去维护各种构建代码,甚至出现这样的代码

  1. gulp.src('/path/to/a.js').pipe(uglify).dest('/path/to/a.min.js');
  2. gulp.src('/path/to/b.js').pipe(uglify).dest('/path/to/b.min.js');
  3. gulp.src('some.html').pipe(findAJSAndReplaceToAMinJS).dest('path/some.html');
  4. gulp.src('some.html').pipe(findBJSAndReplaceToBMinJS).dest('path/some.html');

这样的代码是非常无意义的(压缩 a.js 和 b.js 然后替换 html 里的引用),因为这样的压缩操作不止一个文件不止一个工程。在 coolie 面前,只需要一个标记即可:

  1. <!--coolie-->
  2. <script src="/path/a.js"></script>
  3. <script src="/path/b.js"></script>
  4. <!--/coolie-->
  5. =>
  6. <script src="/js/file_content_md5_version.js"></script>

17苦力本色,为己代言

coolie 做的就这些微不足道的事情,在前端工具风行的年代,coolie 依然我行我素,做好的自己的事情。

当我听到一些说今天学这个工具,明天学那个工具;今天这个工具退出舞台了,明天那个工具退出舞台了;今天 CMD 规范没什么用了,明天 ES2015 模块化出来了;今天 react 火起来了,明天 backbone 没落了;感觉这是一个风风火火的前端世界,其实很浮躁不是吗?

在我的眼中,coolie 正好契合当前的时机,得益于完善的模块化规范,得益于 NodeJS 的诞生,才让它做的如此冷静。

你要说,coolie 会不会退出历史舞台,那我告诉你,很长一段时间都不会。因为coolie 是“苦力”,只做前端开发构建(本质是处理 html、js、css 与资源引用)这一件事,并立志将它做到最好,这是它的本色,也是本事。只要 html、js、css 还在,那么它就不会日落。

coolie 是我的代表作。

原文: https://coolie.ydr.me/introduction/advantage