需求背景 QNSolutions_Web 是一个多项目集成的 repo，front 下是多个项目，而 solution 下是一个 monorepo。 现需要实现当某个项目中有文件变更 commit 时，只对该项目进行 lint-staged 操作，而不是对整个 repo 进行 lint-staged 操作。 Repo 结构如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 . ├── portal │ └── front │ ├── portal-solution │ ├── portal-solution-admin

首先来说一下 npm、yarn、pnpm 的区别 npm vs yarn vs pnpm npm 在 npm3 之前，安装依赖包时采用简单的递归安装方法。而在npm3及之后，采用的是模块扁平化安装。 yarn(摘自https://juejin.cn/post/6964006257715838984) yarn 出生之后，解决了历史上 npm 的某些不足，比如 npm 缺乏对于依赖的完整性和一致性保障，以及 npm 安装速度过慢的问题等，尽管 npm 发展至今，已经在很多方面向 yarn 看齐，但 yarn 的安装理念仍然需要我们关注。 yarn 提出的安装理念很好的解决了当时 npm 的依

一次开发中使用 document.querySelector 发现会报错 使用姿势如下： 1 document.querySelector(`#{xxx}`) xxx 为服务端返回的 uuid 变量，经排查发现当 xxx 是数字开头的时候就会报错。 原因如下： document.querySelector(selectors) 中 selectors 规范是： 包含一个或多个要匹配的选择器的 DOM 字符串 DOMString。 该字符串必须是有效的CSS选择器字符串；如果不是，则引发SYNTAX_ERR异常。请参阅使用选择器定位DOM元素以获取有关选择器以及如何管理它们的更

在 Chrome 音视频播放的时候，play() 返回的是一个 promise，当播放失败的时候一般会显示一个按钮让用户手动进行播放。 但是在浏览其他大型视频网站的时候，会发现他们的网站貌似没出现过该问题。于是去查阅了相关资料。 其实最主要查看 https://developer.chrome.com/blog/autoplay 即可得到答案。 总结就是 Chrome 有个自动播放的策略。 Chrome 中的自动播放策略 改善用户体验，减少安装广告拦截器的动机，并减少数据消耗 Chrome 66 中针对音频和视频元素推出的自动播放策略有效地阻止了 Chrome 中大约一半不需要的媒体

在一次项目开发中，Chrome 调试移动端项目没问题，但是在移动端的 safari 下，会导致 safari 卡死。 后经排查，是将 base64 的数据直接渲染到页面而导致的， 所以解决办法就是过滤掉 base64 的数据渲染。 说一下为什么要把 base64 渲染到页面，因为该项目是作为一个介绍 sdk 的使用姿势，然后展示数据。

一般来说前端架构师在网站搭建初期就要给 z index 分层： * 0+ 用于普通内容 * 16+ 用于导航 * 32+ 用于导航菜单 * 64+ 用于 tooltip * 128+ 用于 popover * 256+ 用于对话框 * 1024+ 用于 loading 类似这样

背景 Chrome 版本: 版本 95.0.4638.54（正式版本） (arm64) 机型如下: * macOS Big Sur * MacBook Pro (13-inch, M1, 2020) * 芯片 Apple M1 * 内存 16GB 一次开发中，一个 post 请求的请求体含有多个 base64 数据，在 Chrome 中请求后遇到如下问题: * http 响应 500 (服务端错误，忽略) * 请求体消失了 * 响应体无法显示 在服务端 500 问题修复之后，起初以为请求体和响应体不显示的问题会导致请求体丢失导致无法正常响应，可是发现只是 Chrome

背景 首先打包出一个 umd 模块的 js 库，这里用 add.umd.js 来表示这个库吧。 然后测试发现： * 在 create-react-app 的项目中通过 import add from 'path/add.umd.js' 方式可以正常引入并使用 * 在 Vite 的项目中(个人测试是通过 yarn create vite 选择 react-ts 模板生成) import add from 'path/add.umd.js' 无法正常导入并使用。然而通过 import 'path/add.umd.js' 却可以正常导入，使用姿势大致如下所示：

背景 在一次开发中，客户提出我们提供的 SDK 无法正常使用，但是我们提供的 demo 可以正常使用。后经对比排查发现，客户的项目中引入了 Mock.js 而导致的 SDK 中对二进制资源的请求被拦截并进行了处理，导致请求的资源发生错误。 产生的原因 后通过在 Mock.js 的 repo issues 里也有搜索到 相关 issue。 原因在于引入 Mock.js 发出请求后，服务器端返回的文件为二进制流，原生请求会正常的将其作为 blob 对象返回，而 Mock.js 则会将其转为字符串，Mock.js 完全重写了原生的 XMLHttpRequest。 如何解决 可以参考该 comm

背景 在一次开发中，服务端需要接受某个参数为 base64 编码的值，测试所得服务端所得的编码值无法与前端所传的值匹配不上，即所传的参数不是服务端所需的正确的编码值。后联调得知，服务端需要接收的是 base64 url-safe 的值，所以前端需要也对数据进行 base64 编码为 url-safe 的值。 遇到问题的相关 issue: https://github.com/brix/crypto-js/issues/252 问题复现 1 2 3 4 5 // 有效的 base64 字符如下: // ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnop