最前端
Stay Hungry, Stay Foolish.
最前端 几乎所有前端项目中都有 yarn.lock / package-lock.json 文件（以下以 npm 为例）。打开浏览，你会发现它长得类似 package.json 的依赖，但是冗长得多。很多同学可能都不知道他们是干什么用的，甚至部分同学在项目跑不起来的时候还会暴力把 lock 文件给干掉，最后反而导致更严重的错误。
那么，lock 文件到底是干什么用的？为什么我们会需要 lock 文件？
# 速度优化
-
减小文件搜索范围
- 配置
resolve.modules:
Webpack 的
resolve.modules配置模块库（即 node_modules）所在的位置，在 js 里出现import 'vue'这样不是相对、也不是绝对路径的写法时，会去 node_modules 目录下找。但是默认的配置，会采用向上递归搜索的方式去寻找，但通常项目目录里只有一个 node_modules，且是在项目根目录，为了减少搜索范围，可以直接写明node_modules的全路径；同样，对于别名(alias)的配置，亦当如此：function resolve (dir) { return path.join(__dirname, '..', dir) } module.exports = { resolve: { extensions: ['.js', '.vue', '.json'], modules: [ resolve('src'), resolve('node_modules') ], alias: { 'vue$': 'vue/dist/vue.common.js', 'src': resolve('src'), 'assets': resolve('src/assets'), 'components': resolve('src/components'), // ... 'store': resolve('src/store') } }, ... } - 配置
# Yeoman 是干什么的？
Yeoman 是一个脚手架生成工具，负责生成一个项目的基本解构，能够节省重复劳动，提升开发体验。
# 开发
Yeoman 为我们提供了 Generator 的基类，于是：
const generators = require("yeoman-generator");
module.exports = generators.Base.extend({
constructor: function () {
generators.Base.apply(this, arguments)
// your logic
}
})
# 安装
CentOS7 环境
安装 Docker:
# 安装依赖
sudo yum install -y yum-utils \
device-mapper-persistent-data \
lvm2
# 添加 docker 下载仓库
sudo yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
# 安装 docker-ce
sudo yum install docker-ce
# 启动 docker
sudo systemctl start docker
# 设置开机启动
sudo systemctl enable docker
# 验证
sudo docker --version
sudo docker run hello-world
# Serif 和 Sans-serif 字体的区别
在西方国家罗马字母阵营中，字体分为两大种类：Sans Serif 和 Serif，打字机体虽然也属于 Sans Serif，但由于是等宽字体，所以另外独立出 Monospace 这一种类，例如在 Web 中，表示代码时常常要使用等宽字体。
Serif 的意思是，在字的笔划开始及结束的地方有额外的装饰，而且笔划的粗细会因直横的不同而有不同。相反的，Sans Serif 则没有这些额外的装饰，笔划粗细大致差不多。如下图：
可以看出，我们平时所用的 Georgia、Times New Roman 等就属于 Serif 字体，而 Arial、Tahoma、Verdana 等则属于 Sans Serif 字体。对中文而言，同样存在这两大种类，很明显，宋体、细明体(繁体中常用)等就属于 Serif，而黑体、幼圆等则属于 Sans Serif。
# 可执行脚本
首先，使用 JavaScript 语言，写一个可执行脚本 hello
#!/usr/bin/env node
console.log('hello world');
然后，修改 hello 的权限：
chmod 755 hello
现在，hello 就可以执行了：
$ ./hello
hello world
Shell 是用户与 Linux 或 Unix 内核通信的工具，shell 编程指的并不是编写这个工具，而是指利用现有的 shell 工具进行编程，写出来的程序是轻量级的脚本，我们叫做 shell 脚本。
Shell 的语法是从C语言继承过来的，因此我们在写 shell 脚本的时候往往能看到C语言的影子。
Shell 脚本实在是太灵活了，相比标准的 Java、C、C++ 等，它不过是一些现有命令的堆叠，这是他的优势也是他的劣势，太灵活导致不容易书写规范。以下整理本人在写 shell 脚本的过程中形成了自己一些规范，这些规范还在实践中，在此分享出来，以期更多的人来帮助我完善。
# 背景
Browserslist 定义了一套浏览器兼容配置标准，使得众多前端开发工具（Autoprefixer, Babel, Stylelint...）之间可以共享同一套配置。
# 查询标准
工具将从以下路径查询 browsers 配置：
- 当前目录或父级目录的 package.json 文件里的 browserslist 配置（推荐）
- 组件自身配置项（比如，
Autoprefixer中的browsers配置项） BROWSERSLIST环境变量- 当前目录或父级目录的
browserslist配置文件 - 当前目录或父级目录的
.browserslistrc配置文件 - 如果以上配置均不能提供一个有效的配置，Browserslist 将采用默认配置：
> 0.5%, last 2 versions, Firefox ESR, not dead
# Service Worker 的生命周期
Service Worker 脚本通过 navigator.serviceWorker.register 方法注册到页面，之后可以脱离页面在浏览器后台运行：
if (navigator.serviceWorker) {
navigator.serviceWorker.register('/service-worker.js')
.then(function(registration) {
console.log('service worker 注册成功');
})
.catch(function (err) {
console.log('servcie worker 注册失败');
});
}
出于安全原因, Service Worker 脚本的作用范围不能超出脚本文件所在的路径。比如地址是 /sw-test/sw.js 的脚本只能控制 /sw-test/ 下的页面。
Service Worker 从注册开始需要先 install, 如果 install 成功, 接下来需要 activate, 然后才能接管页面。但是如果页面被先前的 Service Worker 控制着, 那么它会停留在 installed(waiting) 这个阶段等到页面重新打开才会接管页面, 或者可以通过调用 self.skipWaiting() 方法跳过等待。所以一个 Service Worker 脚本的生命周期有这样一些阶段(从左往右):
