Lsnsh的网络日志
0%

发表于

前言

从第一代 DIV + CSS 正常流的排版方式，到 Flexbox 弹性盒模型，再到 Grid 的排版方式，以及最新的可以利用浏览器渲染引擎的 CSS Houdini。今天我们先来讲一下 Flexbox 弹性盒模型的基础以及如何实现常见布局，并对比传统 DIV + CSS 布局。

阅读全文 »

发表于

1. 互联网是什么？

美国国防部，ARPANET 项目，为了组建承受核弹攻击后仍能保持通信的网络；
多节点，网状结构，互相开放；
部分节点受损后，其他节点仍能以不同的路径，到达目标节点；
互联网不受任何人控制，又或者是受任何人控制，取决于规模和网络管理员，但是由于节点对外开放是性能最大化的，限制出入，不是符合常规的做法或趋势；
由于互联网的存在，轻松的跨域了地域的限制，地球两端的人，能够学习和分享对彼此可能是很有用的知识。

阅读全文 »

发表于

前言

上一篇我们讲到，webpack3.x 升级 4.x 后打包大小优化，今天讲一下 webpack 4.x（webpack 4.43.0） 的打包速度优化，其实在升级了 webpack4 之后对于打包速度就已经有了很大的提升，但是查找时间（缩小范围）、loader 处理时间（多进程）、二次打包时间（缓存）仍有可优化的空间。

打包分析

在优化之前我们需要清楚项目打包的性能情况，这里我们使用 speed-measure-webpack-plugin 插件来进行分析

webpack.base.js

1
2
3
4
5
6
7
8
9
10
11
12
+const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');

+const smp = new SpeedMeasurePlugin({
+  outputFormat: 'humanVerbose'
+});

const webpackConfig = merge(baseWebpackConfig, {
  // ..
});

-module.exports = webpackConfig;
+module.exports = smp.wrap(webpackConfig);

打包看下，本次耗时 62,361 ms，列出了 Plugins 和 Loaders 具体耗时的细节：

图比较长但是基本能看出，其中耗时较多的是 vue-loader 和 ts-loader

阅读全文 »

发表于

前言

上一篇我们讲到，webpack3.x 升级 4.x 时遇到的问题、原因和解决方案，今天讲一下 webpack 4.x 的打包优化。

打包分析

在优化之前我们需要清楚项目的打包情况，npm run build 后 webpack 会将打包信息打印到终端，像这样：

能够看到有好几个文件比较大，但是并不清楚具体包含哪些模块，哪些模块适合单独提取，哪些模块不适合提取，这个时候就需要用到打包分析的工具。

阅读全文 »

发表于

前言

产品需求评审后，各自拆分任务，从 master 分支切出一个 release 分支，根据各自任务情况切出 update 或 feature 的开发分支；

开发调试或提测时，将代码 push 到远程分支，提 merge request（以下简称 mr）到 test 分支，GitLab CI 将项目代码自动构建并部署到测试环境；

测试完毕后提 mr 到 release 分支，待本次需求的开发分支都 code review 并合并后，从 release 分支提 mr 到 pre 分支，GitLab CI 将项目代码自动构建并部署到预生产环境，然后进行回归测试，有问题再从 release 分支切出开发分支进行修改，重复之前的流程。

预生产环境没问题后，从 release 分支提 mr 到 master 分支，，然后打 tag 上线，GitLab CI 将项目代码自动构建并部署到生产环境，然后进行回归测试，有问题再发版。

至此一次需求的完整开发流程就告一段落了，其中构建/部署等一些重复工作都是 GitLab CI 帮我们完成，对此一直很好奇，接下来我们就来尝试搭建一个使用 GitLab CI 的项目。

阅读全文 »

发表于

背景

在 vue-cli3 发布之前，使用 vue-cli2 构建的 vue 项目是基于 webpack3.x 的，伴随着项目的版本迭代，功能逐渐增多，文件也逐渐增多，打包时间从最初的 4.5 分钟，最久的时候 17 分钟。

因为使用 ts 的缘故，每次打包 ts-loader 需要进行类型检查，导致耗时剧增。权衡利弊下，将 ts-loader 的类型检查禁用后（transpileOnly 选项设置为 true），打包时间锐减到 1 分钟。

随着时间的推移，项目依赖逐渐落后，打包时间也到了 2.5 分钟，恰逢 webpack4 对于打包性能的提升，于是就有了这篇升级日志：

起步

整体思路：

  1. 升级项目依赖
  2. 跑通开发环境打包
  3. 跑通生成环境打包

升级项目依赖

一开始的项目依赖升级的思路是，先升级 webpack 到最新的版本，然后逐步升级 loader 、plugin 、babel 等依赖。但是基于之前其他项目升级 webpack4 的经验，发现逐步升级会耗费一部分时间在新旧依赖的问题上，于是决定激进一点，使用 ncu 一次性将 package.json 中包含的项目依赖升级到最新版本，考虑到不确定性，可以选择性的修改 package.json 不升级某些依赖，比如主要版本号有变动的依赖（eg: 0.x.x => 1.x.x）。

1
2
3
4
5
6
7
8
9
10
11
12
13
# 安装 npm-check-updates
npm i -g npm-check-updates

# 检查项目依赖的版本与最新稳定版本，列出清单（beta版本可能不会列出来）
ncu

# 将 `package.json` 中包含的依赖的版本号，更新到最新
ncu -u

# 删除旧的依赖，安装新的依赖
rm -rf node_modules
rm package-lock.json
npm i
阅读全文 »

发表于

起因

之前在网上看文章提到说，通过 apt-get 的方式安装 nginx，可能安装不是最新版本的情况，考虑到在 Ubuntu 下第一次安装 nginx，以后肯定会有卸载重新安装新版本的需求，刚好刚开始学习 nginx，索性练习下卸载重装的过程。

安装

使用 Ubuntu 下的包管理工具 apt 来安装 nginx

1
$ sudo apt-get install nginx

卸载

同样使用 apt 来卸载 nginx

1
$ sudo apt-get remove nginx

sudo apt-get autoremove命令帮我们卸载不再需要的依赖包
在这里我们卸载 nginx 相关的依赖包

1
$ sudo apt-get autoremove

删除 nginx 配置文件夹

1
$ sudo rm -rf /etc/nginx

重新安装 nginx

1
2
3
# 更新源
$ sudo apt update
$ sudo apt-get install nginx

然而控制台报错：

阅读全文 »