某个版本之前都是通过HTTP安装托管在git源上的npm包的，然而似乎某个版本开始就有可能采取SSH连接的方式。然而，SSH需要SSH Key才可以连接到git源（仅以Github为例），这样的策略会导致在一些CI上无法安装依赖（例如Vercel），得到这样的错误： 这个问题碰到很久了。观察发现在安装时，会随机地从HTTP或Git拉取包，所以每一次安装依赖以后，Git包的来源都可能发生变化。所以之前都是反复安装然后最终得到从加载的结果时再上传。是的，很粗暴。 今天终于想彻底地修一下这个问题。机缘巧合找到了这么一篇GIST，引用如下： 试了一下果然管用，爽到。 当然也可能是正好随机到codeload了？有待观察。 所以我之前又翻文档又翻文档试图找到一个config或者cli option来解决问题实在走错路了，

来源

假设有这么一段代码， 你的Webpack配置报了下述的错误： 你尝试把改为，很快你会发现无济于事，因为ESM的限制规则在它之上。 其实如果写了（但是他们甚至没把esm导出写进package.json），或者你的工程是传统的cjs工程，亦或是你给每个导入都加了扩展名（虽然好像确实有利于解析速度但是真的会有人写嘛）那么你不会遇到这个问题。在编译期最快的解决方案果然还是用webpack配置，顺带也解决一下的默认导入不是esm的问题： 注意dayjs后的$是必要的，它代表精确匹配，否则之后的两个规则都不会命中。你或许可以试试反着写可不可以。 封面图出处：https://www.pakutaso.com/20200930251post-30704.

来源

你现在有一个包含许多软件包的单体仓库。你的公用组件包引入了一个第三方组件包（假设是antd），你的两个客户端包和也引入了antd，当然也引入了公用组件包。你在中使用了第三方组件包中的一个Context的Provider（假设你在做一个多端的React应用），你把代码在包下的这个Context的Consumer嵌套在这个Provider的下边。正常来讲，这个Consumer应当能够读到Provider提供的Context值。bug出现了，这个Provider并没能读到Context的值，就好像它的父级根本没有Provider一样。然而同样的代码在中就跑的通，这是为什么呢？ 今天这篇文章将会讲述一件由pnpm的依赖解析机制引发的问题。pnpm解决了安装npm包的许多痛点，然而其一些安装策略有可能会导致一些奇怪的行为，并且一时间很难发现。如果你还不知道pnpm是啥，

来源