Skip to content

build.md

Latest commit

 

History

History
188 lines (132 loc) · 6.59 KB

build.md

File metadata and controls

188 lines (132 loc) · 6.59 KB

构建系统

上一章：文件目录

为什么需要构建系统

在上一章文件目录中的文件结构，存在一些未解决的问题。

/m/btn/index.less 如果要在视图代码中使用，不使用构建系统分别可以通过以下3种方式使用。

  1. 在 /view/login/index.html 中通过 <link href="../../m/btn/index.css" /> 引用
  2. 在 /view/login/index.css 中通过 @import url(../../m/btn/index.css); 引用
  3. 复制 /m/btn/index.css 文件内容到 /view/login/index.css 中

1和2两种方式都会增加一个新的HTTP请求数，页面需要加载 /m/btn/index.css 和 /view/login/index.css。第三种方式很傻不易于维护 btn 样式一旦修改就要手动同步到多个地方。

可能读者会有疑问：

直接把 btn 代码写到 view/pc/index.css 然后在所有页面调用这个css文件就解决了资源重复加载和手动同步的问题。

但是 btn 模块的代码放在 view/pc/index.css 中，违反了文件目录中提到的资源就近维护的原则。

这时我们就要使用CSS预处理器来帮助我们解决这个问题。比如 Less Sass。

比如在 Less 中可以通过 @import (less) "../m/btn/index.css"; @import "../m/btn/index.less"; 或 的方式引入 css 或 less 。

// view/login/index.less
@import (less) "../m/btn/index.css";
.login-title {
    font-size:20px;
}

通过编译文件会变成

/* view/login/index.less */
.m-btn {
	border:1px solid #EEE;
	background-color: #fafafa;
	color:#333;
	box-sizing: border-box;
}
.m-btn--danger {
	color:pink;
	border-color:red;
}
.login-title {
    font-size:20px;
}

还需要让构建系统检测 /m/btn/index.css 和 /view/login/index.less 被修改时立即编译 less。

而 /m/switchClass/index.js 也会遇到跟 /m/btn/index.css 相同的问题，这在JS方面统一使用 webpack 解决。webpack-book

构建系统不等于前端工程

本书的章节顺序是文件目录在构建系统的前面，是为了纠正一个问题。

一定要先知道问题是什么，然后用构建工具解决这个问题。而不是学会了构建工具的使用，就按照固定的使用方式解决问题。

构建工具教程的的使用示例都只是单一场景，因为它是教程所以没法做到覆盖所有项目情况。需要使用者自己根据项目情况深思熟虑后判断如何使用。

构建工具对源码的侵入越少越好

px to rem(不要用这个方案)

/* 源码 */
body {
    border-top: 1px;
    border-bottom: 10px;
    padding: 10px; /* @norem */
    background-size: 10px 10px; /* @rem */
}
/* 输出 */
body {
    border-top: 1px;
    border-bottom: 0.5557rem;
    padding: 10px;
    background-size: 0.5557rem 0.5557rem;
}

直接阅读源码会认为 body的各项单位设置的就是px，会带来误导。而且 /* @norem */ 的标记非常麻烦。

less function

编译 rem 这种需求应该使用CSS预处理器的函数功能解决

less-rem

// 源码
@import "./rem";
.demo {
    width:rem(640);
    height:rem(100);
    box-shadow: rem(11) rem(22) rem(33) pink;
    background: #eee;
}
// rem.less
.function {
    .rem(@size) {
        // 640 是设计稿宽度
        // 640 is psd width
        return: @size/(640/320*16)+0rem;
    }
}
/* 输出 */
.demo {
  width: 20rem;
  height: 3.125rem;
  box-shadow: 0.34375rem 0.6875rem 1.03125rem pink;
  background: #eee;
}

直接阅读源码可以追踪到 rem.less 就会明白这个项目的 rem 计算标准是什么

构建工具的选择

因为自己搭建前端工程的构建系统才需要看这一部分所以内容移动到了 issues，各种坑都在 issues 中。

构建工具的组合

gulp fis webpack 应该组合使用，因为：

  1. gulp 虽然有 gulp-webpack 但是构建速度完全比不上单独启动一个服务器加上 webpack-hot-middleware 。
  2. fis3 虽然有 fis3-parser-webpack 但是做不到异步加载和热更新。
  3. webpack 虽然能提取单独样式文件 但是不可能用它提取所有文件。还是需要 fis3 或者 gulp 构建非JS文件。

所以 gulp-webpack fis3-parser-webpack webpack提取单独样式文件 都不要用。

那么就要选择 gulp 或 fis3 作为构建工具。因为 静态资源映射表 的原因，作者选择 fis3。当然你也可以选择 gulp ，毕竟可以改造它们以满足自己的需求。只是时间成本和技术成本都很高，对两个构建工具做详细了解后选择改造工作量最小的。时间充裕的情况下多花点时间了解（磨刀不误砍柴工）。

本地开发阶段：非 js 文件用 gulp fis3 构建，js文件使用 webpack-dev-middleware 和 webpack-hot-middleware 构建。因为 webpack-dev-middleware 速度非常快。

如果选择 fis3 注意：最终构建时，先用fis3构建一遍所有文件，然后用webpack构建一遍js文件，都构建到同一个文件夹。然后再用fis3 构建一次生成文件指纹的文件（md5）。因为 js 交给 webpack 构建所以不能达到直接用fis3构建所有文件并加上文件指纹。

参考

onface/react-project 是基于 react 技术栈的前端工程解决方案

markrun

markrun 主要的功能是

源码

````js
document.title = "js - basic a 18"
````

输出

<pre>
    document.title = "js - basic a 18"
</pre>
<script>
    document.title = "js - basic a 18"
</script>

利用 markrun 配合构建系统就能在 /m/**/README.md 中 编写一份代码，生成的html中出现 pre 和 script/style/html

单独列出 markrun 是因为提高了模块的文档编写速度开发人员就更愿意写文档，能在开发模块的同时完成简单的使用示例编写。

下一章：技术选型