阮一峰ES6链接

我们平时经常看到一种引入方式：import UnoCSS from 'unocss/vite'，这种带斜杠的引入其实就是 exports 字段发挥的作用。

我们如果不配置 exports 字段的话，直接斜杠进入到的是包下面的路径，比如我们平时也会这样引入：import bar from 'foo/index.js'。

背景

公司内部的日志系统使用的是 ELK 框架，即 ElasticSearch、Logstash 和 Kibana 三个开源组件结合使用，完成更强大的用户对日志的查询、排序、统计需求。一般这套框架上还会使用 Filebeat 这个组件用于监控日志的变化，并传给 Logstash 这个管道。

流程是：Filebeat 监控日志变化并收集日志，通过 Logstash 这个管道上报到 ElasticSearch 中，最终通过 Kibana 展示 ElasticSearch 中的数据。

我这边是前端开发，因此需要关注的点主要在日志的收集与上报这块，这一块是和后端不一样的，后端使用了公司集成的开发框架即可实现开箱即用的日志上报功能。前端侧这边在公司的大前端部门也有提供对应的日志与埋点上报 SDK watchdog。

@apply 指令

由于是 tailwindcss 切 unocss，其中有 @apply 指令还是挺好用的。在 unocss 这边，有两种实现方式：

1. 使用 @unocss/transformer-directives ，该方案仅支持 Vite
2. 使用 @unocss/postcss ，该方案支持 Webpack 但需要安装 postcss

由于项目较大，目前暂时不考虑迁移 Vite ，因此只能采用 postcss 的方案来支持 @apply。

背景

由于项目中 lock 文件被删，重新安装依赖后发现许多依赖都自动升级到最新版本了，因此想着干脆对项目中的依赖进行一次统一升级。在升级了 webpack 后，顺便将一些 loader 也进行升级，升级后出现了一系列的问题。

mini-css-extract-plugin 导致 url() 引入报错

今天在 1.3.9 版本时，发现 publicPath 设成 '../' 时，引入的字体文件链接变成了这样：src:url([file:///Users/crab.huang/Project/abtest.web/node_modules/.pnpm/css-loader@6.7.3_webpack@5.77.0/node_modules/css-loader/dist/cjs.js!/Users/crab.huang/Project/abtest.web/node_modules/.pnpm/less-loader@3.0.0_less@2.7.0/node_modules/less-loader/lib/loader.js!/Users/crab.huang/Project/abtest.web/src/common/font/element-icons.ttf](file:///Users/crab.huang/Project/abtest.web/node_modules/.pnpm/css-loader@6.7.3_webpack@5.77.0/node_modules/css-loader/dist/cjs.js!/Users/crab.huang/Project/abtest.web/node_modules/.pnpm/less-loader@3.0.0_less@2.7.0/node_modules/less-loader/lib/loader.js!/Users/crab.huang/Project/abtest.web/src/common/font/element-icons.ttf))

背景

有一天发现线上打包平台报代码使用了 esnext 语法，因此感觉可能是 babel 没配置好，在探索 babel 的过程中又重新梳理了一次 webpack 相关的规则。

loader

loader 的配置中如果 exclude、include、test 都出现在同一个 loader 的配置中时，优先级是 exclude > include > test。

loader 本质上是一个数组，里面有不同的 rules 匹配规则。接受到一个文件时，会从上到下找到匹配的 rules，当匹配到对应的规则时会按顺序将代码传输到 use 下面的 loader 中，此时统一规则的 loader 则是按照从下到上的顺序执行的。

参考链接：

姜瑞涛的 babel 教程

babel 官方文档

babel 中文文档

组合式 API (Composition API) 是一系列 API 的集合，使我们可以使用函数而不是声明选项的方式书写 Vue 组件。

在刚接触 Vue3 的时候，由于了解到 Vue3 最大的变化就是提供了全新的 composition api，因此在初上手的时候，所有组件清一色用的都是 <script setup> + coposition api 编写，想着多用新特性总没错。在经历了一段时间的使用后，才逐渐有了一些自己的理解。

在我看来，组合式 API 不是 Vue3 的必须品，它有些时候更像一种编码思维，在该用到的地方使用会给你提升十分多的效率，但如果是为了用而用，在大多数简单的场景下，可能选项式 API 会显得更简单无脑一些，因为它给你列好了框架，手把手教你该把代码放在哪里。官方的原话是：

Vite1仅仅试用过，Vite2已经更新了，全新插件架构，丝滑的开发体验，和Vue3的完美结合。 出于对尤大的信任与新技术的追求，在做毕设的我尝试着把项目移植到 Vite2 上。

Vite2 官方文档（看了一个星期的英文文档才发现原来中文文档也更新了 T.T）

目标

由于 husky 这个插件在升级到 5.+ 的版本后有一个配置上的更新，因此需要对现有项目中的配置文件进行重新配置。如果现在有项目使用 4.x 版本想升级的也可以进行升级。

附上官方文档，有什么问题可以先自己看一下官方文档~

1. 升级husky版本（如果不需要可以跳过）

   更改 package.json 里面的版本号为最新，然后sudo lnpm install即可。

2. 初始化新版 husky

   新版 husky 需要有一个 install 的操作，安装新版后需要执行husky install命令，刚 clone 下来的项目也需要进行 install 操作，同理。

3. 根据之前的配置文件重新配置

   一般来说，现有项目的 husky 配置都在 package.json 中，可以看到有 husky 的相关配置，例如：

先上一个 github 地址 https://github.com/unjs/unplugin

前言

前端工具链生态是日新月异，很多人 webpack 都还没玩熟悉呢，新的 vite 都要出到 3.0 了，再说 vite 是基于 rollup 和 esbuild 的吧，这些个工具都各有优劣，都是要学习的东西。但在我看来，这些工具都有一个共同的特点：都是打包工具。打包工具需要做的事情就很简单，接收输入的文件，输出成我们想要的东西，这其中还包含了可以通过不同的插件实现对输入文件的处理，以实现混淆、注入等功能；同时打包工具大多都提供了许多钩子（hook），贯穿整个打包流程，也方便了我们对打包过程的关注和额外处理。百变不离其宗，webpack 有 loader 和 plugin，vite 扩展了设计出色的 Rollup 接口，还带了一些 vite 独特的配置项，因此有人就有了写一次代码，适配多个 bundler 的想法，unplugin 就是这样一个存在。