think of babel
babel 配置
@babel/perset-env
useBuiltIns
介绍
useBuiltIns是用于配合core-js,兼容旧版本浏览器原生不支持的新功能.枚举的值为: ‘entry’, ‘usage’ and false.
‘entry’
- 配合 corejs: 2 时,会在入口直接导入全部的兼容代码.
- 配合 corejs: 3 时,会在入口支持按需导入兼容代码.
false
- 在任何位置不导入任何兼容代码.
‘usage’
- 配合 corejs: 2时, 会在需要兼容的模块内导入全部的兼容代码.
- 配合 corejs: 3时, 根据使用时的旧版本浏览器原生不支持的新功能按需在需要兼容的模块内进行导入.
think of testing
测试(testing)
跨终端自动化测试
在介绍自动化测试之前,先来说一下跨终端测试工具,基于全方位测试需求的考虑,跨终端测试应该是最重要的类型之一.如今,各种类型的浏览器、操作系统、品牌手机以及设备可谓是琳琅满目.因此,需要确保用户在通过不同种类的浏览器、操作系统、品牌手机以及设备访问平台服务时,不会产生较大的体验落差.
在市面上,诸如 LambdaTest 之类的在线工具,就能够帮助以一种轻松互动的方式,解决此方面的问题.LambdaTest 是一种非常流行的在线工具,可以通过它对超过3000多个真正的浏览器、操作系统、品牌手机以及设备进行跨终端式的测试.测试人员甚至可以使用该工具来自动捕捉屏幕上的截图,以加速对于目标平台网络布局的测试.另外,其他同类型比较流行的测试工具还有:Browserstack 和 Saucelabs.
lambdaTest
lambdaTest 能够为3000多种浏览器、不同的 Web 应用操作系统、品牌手机以及设备的组合提供支持,可以在线执行手动测试(Manual testing)、自动化测试(Automatic testing)以及真机测试(Real Device testing).
think of typescript
typescript 配置
{“module”: “umd”}
问题1
近期在配置 typescript 配合 webpack 构建打包项目时发现,tsconfig.json 里配置模块导入导出模式为 {“module”:”umd”},webpack 使用 ts-loader 来处理,导入导出的模块模式同样使用 {libraryTarget: ‘umd’} or output -> library: {type: ‘umd’},构建打包出来的模块竟然不识别(下图就是模块不识别的异常)……反之,我配置为 {“module”:”commonjs”},webpack 采用同样的配置,构建打包出来的模块就是可以识别的,并且运行很正常.
奇事.
- 标准 “umd” 中不是包含 “commonjs” 吗?
- webpack 为啥在模块导入导出模式中会出现只识别 typescript {“module”:”commonjs”},而不识别 typescript {“module”:”umd”} 呢?
异常.
think of postcss
think of JsModule
think of webpack
webpack 配置
output
问题1
近期在配置 webpack 时,发现 output -> libraryType: ‘umd’ or output -> library: {type: ‘umd’} 打包构建导出的模块无法实行 TreeShaking.为什么?
介绍.
在配置 webpack 的输出 output 时,都会遇到输出模块的配置,也就是 webpack4 中的 libraryType 以及 webpack5 中的 libraryType(未删但新特性不更新) and library: {type: ‘xxx’},首先解释一下这几个属性的含义,libraryType 指的是每个 chunk 模块以怎样的模块形式构建打包输出,而 library: {type: ‘xxx’} 在webpack5 中属于对 libraryType 的复写,跟 libraryType 是一个含义.
libraryType 的值枚举.
1
2
3
4
5
6
7
8
9module.exports = {
//...
//值枚举
//'commonjs' | 'commonjs2' | 'amd' | 'umd' | 'this' | 'var' | 'global' | 'module'
output: {
libraryType: 'commonjs'
}
//...
};libraryType 中包含模块导入导出的值枚举.
‘commonjs’ | ‘commonjs2’ | ‘amd’ | ‘umd’ | ‘module’ 这五个值枚举代表了模块导入导出历史的发展轨迹,由最初的 commonjs 到最终方案 esm,关于它们的含义以及对比,这里把它放在了think of JsModule#模块导入导出的历史中,这部分非常重要,是为后续下文的理解做铺垫.
TreeShaking.
TreeShaking 最初是 RollUp 团队推出的一个方案,以 esm 模块导入导出模式的静态分析为依赖基础,在编译时对项目代码进行瘦身,将无用、空引入的代码模块不构建进打出的包中,减少代码体积,减少项目冗余,提高项目运行速度的模式.
import umd.
对于 umd 的 esm import 导入,在 commonjs、NodeJS 环境下都可以实现,但是必须注意 esm(ecmascript module) NodeJS ESM部分.
结论.
由于上述 umd 所兼容的所有模块导入导出模式不能实现静态分析,包括 import 配合 module.exports (使用 esm import 导入 commonjs2 值枚举导出的模块),而 TreeShaking 又是以 esm 模块导入导出模式的静态分析为依赖基础的,所以 umd 模块导入导出模式不能实行 TreeShaking.
命令行
think of homebrew
think of git
git命令
git remote add origin git@github.com:white-than-wood/white-than-wood.github.io.git
从官方对于 git remote 的定义来看,意思是列出本地拥有的每个指定远程句柄的简称.简单来说本地与远程交流的一个简化链接,当在本地建立起一个已经初始化的 git 项目时,势必要与远程 git 库建立联系(远程 git 库本来也是为了保存代码、保证多人开发时代码的同步以及简化其流程性而存在的),那么此命令就是为了在本地建立一个句柄简称与远程链接 git@github.com:white-than-wood/white-than-wood.github.io.git 进行关联,实行通信,不需要再去 copy 使用 github 远程库上面的链接.
git push –set-upstream origin master
在本地句柄简称 origin 建立了与远程代码库的关联之后,首次推送同步代码,需要设置推送、同步代码的上游远程分支,当首次设置之后,后续无需设置. –set-upstream origin master 就是设置推送、同步代码的本地 origin 句柄简称的上游分支为 master.
git merge master –allow-unrelated-histories