写在前面

之前我们已经讲解了koa源码中的一些依赖包，Koa源码系列之依赖包解析 Koa源码系列之koa-compose，现在我们来看看koa源码的全流程

解析

我们首先来看看最简单的用法，一下是官网的示例

1
2
3
4
5
6
7
8

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = 'Hello World';
});

app.listen(3000);

首先我们引入koa包，然后实例化一个对象，也就是const = new Koa()。然后调用use方法，这个方法之前在Koa源码系列之koa-compose讲过，用处就是挂载中间件。当前内部执行的方法就是向前端返回一个hello world的内容，最后我们将应用挂载在3000端口下，这个listen很重要，因为一切我们定义的的方法都会从这里执行。我们看看 Koa 的构造函数的主入口是从哪暴露的，先来🤔思考一个问题，我们怎么快速找到一个包的主入口呢？如果你发布过npm包就知道，我们可以在package.json内找到main，koa的内容是 "main": "lib/application.js"，现在我们可以直接去查看lib下的application文件，是不是很方便？

接下来部分解析可能在代码注释内
https://github.com/koajs/koa/blob/master/lib/application.js#L30

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

module.exports = class Application extends Emitter {
  constructor(options) {
    super();
    options = options || {};
    this.proxy = options.proxy || false;
    this.subdomainOffset = options.subdomainOffset || 2;
    this.proxyIpHeader = options.proxyIpHeader || 'X-Forwarded-For';
    this.maxIpsCount = options.maxIpsCount || 0;
    this.env = options.env || process.env.NODE_ENV || 'development';
    if (options.keys) this.keys = options.keys;
    // 存放中间件
    this.middleware = [];
    this.context = Object.create(context);
    this.request = Object.create(request);
    this.response = Object.create(response);
    if (util.inspect.custom) {
      this[util.inspect.custom] = this.inspect;
    }
  }
  ...
}

写在前面

上一篇我们讲了 Koa源码系列之koa-compose，其实也可以归为到这篇文章。今天开始我们看看Koa源码中使用了哪些包，他们起到了什么作用。ps: 这里不准备讲所有的包

is-generator-function

https://github.com/koajs/koa/blob/master/lib/application.js#L122

1
2
3
4
5
6
7
8
9
10
11
12

use(fn) {
  if (typeof fn !== 'function') throw new TypeError('middleware must be a function!');
  if (isGeneratorFunction(fn)) {
    deprecate('Support for generators will be removed in v3. ' +
              'See the documentation for examples of how to convert old middleware ' +
              'https://github.com/koajs/koa/blob/master/docs/migration.md');
    fn = convert(fn);
  }
  debug('use %s', fn._name || fn.name || '-');
  this.middleware.push(fn);
  return this;
}

可以看看上面一段代码，koa在注入中间件的之前先判断传入是否是函数，然后判断当前传入的函数是否是 generator，如果是 generator 那么使用convert（koa-convert包，下面会讲到）进行转换，其实转换出来返回的是一个 promise，那么怎么判断是否是 generator 函数的呢？使用了isGeneratorFunction方法，也就是 is-generator-function包，下面是源码

写在前面

从今天开始阅读学习一下Koa源码，Koa对前端来说肯定不陌生，使用node做后台大部分会选择Koa来做，Koa源码的代码量其实很少，接下来让我们一层层剥离，分析其中的源码

Koa用法

1
2
3
4
5
6
7
8

const Koa = require("koa");
const app = new Koa();
app.use(async ctx => {
  ctx.body = {
    a: 1
  };
});
app.listen(3000);

浏览器打开 http://localhost:3000 可以看到返回了一个对象 {a:1}

什么是Docker？

Docker 是一个开源的应用容器引擎，可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化

为什么要用Docker

更高效的利用系统资源

由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销，Docker 对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。因此，相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用。

更快速的启动时间

传统的虚拟机技术启动应用服务往往需要数分钟，而 Docker 容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。

因为项目一直都是使用gitlab进行自动化部署，但是都是前人种树，后人乘凉的现状。难得抽空花了一点时间来玩一下gitlab的CI

官方README

准备工作

• 一台服务器
• 注册gitlab账号，并且新建一个项目

新建.gitlab-ci.yml

项目下新建文件 .gitlab-ci.yml，你也可以使用Web IDE 在线新建文件

安装Gitlab Runner到服务器

登录你的服务器

1
2
3
4
5
6

# For Debian/Ubuntu
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ sudo apt-get install gitlab-ci-multi-runner
# For CentOS
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ci-multi-runner

vuex使用

当前vuex版本：3.1.0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import Vue from 'vue';
import Vuex from 'vuex';

Vue.use(Vuex);
const state = {
  test: 1
}
const actions = {
  changeTest({ commit }, payload){
    commit('setTestValue', payload)
  }
}
const mutations = {
  setTestValue(state, payload){
    state.test = payload
  }
}
export default new Vuex.Store({
  state,
  actions,
  mutations,
})

1
2
3
4
5
6
7
8
9

import Vue from 'vue';
import store from './store';

new Vue({
  el: '#app',
  store,
  template: '<App/>',
  components: { App }
});

首先我们先注册vuex，然后设置一些state/mutation/actions 实例化出来，最后交给 Vue 处理

写在前面

webpack的loader的应用是非常广泛的，完全离不开它，我们开发的过程往往都是使用别人编写好的loader来处理文件，今天我们就来编写一个loader。

基础

首先我们看看loader是怎么使用在webpack上的

1
2
3
4
5
6
7
8
9
10
11

module.exports = {
  entry: '...',
  module: {
    rules: [
      {
        test: /\.css$/,
        use: 'css-loader',
      },
    ],
  },
}

使用起来很简单，如果你需要处理css文件，那么安装好css-loader包，然后正则匹配到所有.css的文件，使用css-loader进行文件得处理

写在前面

使用webpack或者自己配置研究过webpack的人都知道plugin，也就是webpack的插件，对于大多数人来说，经常使用的插件诸如：clean-webpack-plugin、html-webpack-plugin等等，在很多情况下，我们只会去用它，知道他是干什么的，但是其内部做的操作缺知之甚少，今天我们就来写一个plugin

基础

首先我们看看插件是怎么使用在webpack上的

1
2
3
4
5
6
7
8
9
10
11
12

const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
  entry: '...',
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      template: './index.html',
    }),
  ]  
}

写在前面

上一篇文章我们讲了如何使用 webpack，执行打包会在 dist 生成一堆文件，那么 webpack 输出的文件里面到底长啥样呢？用过的人100%看过，大部分的还是压缩混淆后的代码，一般我们不会去关心它，只管当前持续运行正常就行了。今天我们来看看 webpack 输出的文件

配置

安装

开发环境 webpack: 4.34.0

1
2

> npm init -y
> cnpm i webpack webpack-cli -D

新建文件

新建文件 webpack.config.js
新建文件夹 src
webpack.config.js

1
2
3
4
5
6
7
8
9
10

const path = require('path');
module.exports = {
  devtool: 'inline-source-map',
  mode: 'development',
  entry: './src/main.js',
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'bundle.js',
  },
};

写在前面

相信webpack这个名称对于前端的同学来说并不陌生，只要你在用vue、react等等之类的框架，就得天天和它打交道。但是大部分人都只是直接怼一个vue-cli脚手架生成一个项目，运行起来就开始一顿写，完全不会去看这个项目的其他相关的东西，今天开始，咱们就来说说这个又爱又恨的webpack

问题

使用wepack的时候经常会出现下面这些疑问

1. 你webpack只能打包单页面的文件吗？
2. WTF，我包怎么这么大，加载太慢了
3. 我打包速度怎么这么慢，什么破玩意？
   …

为什么要使用webpack

哈，你问我为什么要用？因为大家都在用啊😃😃。开个玩笑，前端发展到今天，新技术新思想新框架爆发式增长，当前的浏览器环境跑不赢啊，你说你写个ES6/7在浏览器环境都能跑起来？扯淡的。这个时候babel就出现了，你跑不起来是吧，那我转成ES5你总该跑起来吧~，那babel我还是不能直接用啊，肯定得借助工具编译呀，所以我们需要webpack去做这件事情了。这个时候有人就要站出来说了，我gulp不服，我也能做，我就不用webpack。你这么说我就要跟你唠唠了，现在我们先来比较一下webpack和gulp。

gulp 是 task runner，Webpack 是 module bundler

webpack的优势在模块化，gulp除了模块化方面都很不错。但是前端发展至今，模块化真的很重要，CMD、AMD就是模块化的产物。
简单来说，如果你当前项目需要模块化编程，那就选webpack，如果是处理其他事情，比如把图片拼接成雪碧图或者压缩，那么gulp是最擅长的

感兴趣的可以看看这个回答 gulp 有哪些功能是 webpack 不能替代的？

安装

这里可以参考webpack官网
开发环境 webpack: 4.34.0

1
2
3

> mkdir webpack && cd webpack
> npm init -y
> npm install webpack webpack-cli -D

入口（entry）

每个webpack都会有一个entry，就是入口的意思，指示 webpack 应该使用哪个模块，来作为构建其内部依赖图的开始。

注意点：

1. 入口可以有多个，如果是单页面只需要一个入口，多页面可以设置多个入口
2. 入口的文件必须是.js文件，因为webpack只认识js（不完全对，其实任意文件都可以，只是webpack会把它当做js来处理）

举个🌰