单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。简单来说，单元就是人为规定的最小的被测功能模块，可能是一个单一函数或方法、一个完整的组件或类。
单元测试是最小巧也是最简单的测试——它们通过隔离单个组件的每一个部分，来在最小工作单元上进行断言。
单元测试侧重：检验函数的输出结果
e2e (端到端) 测试，致力于确保组件的一系列交互是正确的。它们是更高级别的测试，例如可能会测试用户是否注册、登录以及更新他们的用户名。这种测试运行起来会比单元测试和快照比对测试慢一些。
e2e测试侧重：从用户视角，对真实系统的访问行为进行仿真
之前已经写过相关NPM的文章，这次算是补齐了一个系列的了。
这个系列的顺序：NPM组件搭建(本篇) ---> 本地开发调试NPM包 ---> 在NPM上发布组件教程 ---> GitHub Action终章之发布NPM
新开发或修改的 NPM 模块，如何在项目中试验？最近在做小工具，这个问题摆在面前！但其实 npm 本身已经对此类情况提供了专门的 npm link 指令。
最近写的函数库，使用了TS，整理下笔记。
起因还是由于封装的函数库里面有一个精度计算的问题，代码如下：
const addExact(arg1, arg2) => {
let r1, r2, m;
try {
r1 = arg1.toString().split('.')[1].length;
} catch (e) {
r1 = 0;
}
try {
r2 = arg2.toString().split(".")[1].length;
} catch (e) {
r2 = 0;
}
m = Math.pow(10, Math.max(r1, r2));
return Math.round(arg1 * m + arg2 * m) / m;
};在有些情况下，我们可能需要对一个 prop 进行“双向绑定”。不幸的是，真正的双向绑定会带来维护上的问题，因为子组件可以变更父组件，且在父组件和子组件都没有明显的变更来源。今天扒拉官方文档，发现.sync这块还是理解的不是太好，于是写一个demo，做一下记录。
在vue构建页面的顺序为，父组件构建 → 子组件构建 → 父组件获取异步数据 → 子组件获取父组件异步数据 → 子组件更新，也就是说构建的时候生命周期只会执行一次。
没有一种架构是可以满足所有迭代的需求的
架构并不是只限于技术选型，架构作为软件生命周期的一部分！软件的生命周期包含了迭代、维护、重构等过程，架构设计亦是如此，所以说架构是需要变化的，目的就是适应当前情况的开发场景。
而架构产生的时间，必定是受到当时的约束条件，如人力、团队技术积累、时间、业务定位等等需求。所以，当前架构可能并不能满足未来的需求，我们要开放对待这个问题，只要当前的架构符合一定的设计原则，未来进行架构的演进就不是问题。
“架构”这个词解释也没有一个明确的定义，每个层级，每个场景都有自己的解释，所以到底什么是架构呢？
周末随手看Vue的api文档，看到了vm.$attrs这个，官方是这么解释的：
包含了父作用域中不作为prop被识别 (且获取) 的attribute绑定 (class和style除外)。当一个组件没有声明任何prop时，这里会包含所有父作用域的绑定 (class和style除外)，并且可以通过v-bind="$attrs"传入内部组件——在创建高级别的组件时非常有用。
看完之后发现，这些解释比较晦涩，官方也没有具体的例子来解释！还是自己动手整个demo来看看吧！！！
之前用cli脚手架搭完之后，直接把vue.config.js丢项目根目录就完事了，前几天用脚手架重新搭了个项目，安装完各种依赖之后，运行竟然莫名其妙的报错了：
ValidationError: Invalid options object. Sass Loader has been initialised using an options object that does not match the API schema.本文章适用于用Cli3脚手架搭建的项目，这里我拿已有项目为例，所以项目搭建之类的就不在这里一一描述了。
Windows Terminal 是一个全新的、流行的、功能强大的命令行终端工具。包含很多来社区呼声很高的特性，例如：多 Tab 支持、富文本、多语言支持、可配置、主题和样式，支持 emoji 和基于 GPU 运算的文本渲染等等。同时该终端依然符合我们的目标和要求，以确保它保持快速、高效，并且不会消耗大量内存和电源。