假设有这么一段代码， 你的Webpack配置报了下述的错误： 你尝试把改为，很快你会发现无济于事，因为ESM的限制规则在它之上。 其实如果写了（但是他们甚至没把esm导出写进package.json），或者你的工程是传统的cjs工程，亦或是你给每个导入都加了扩展名（虽然好像确实有利于解析速度但是真的会有人写嘛）那么你不会遇到这个问题。在编译期最快的解决方案果然还是用webpack配置，顺带也解决一下的默认导入不是esm的问题： 注意dayjs后的$是必要的，它代表精确匹配，否则之后的两个规则都不会命中。你或许可以试试反着写可不可以。 封面图出处：https://www.pakutaso.com/20200930251post-30704.
最近刷小红书的时候老是看到这个。正好雪先生@yuki 去日本现充，就拜托他去DAISO看看有没有机会碰到。然而雪先生去的DAISO都没有… 然后一天晚上（11点半）雪先生给我发这个照片： 给你图 你看看来做个适配手机的 非常环保减塑 那既然都这么说了，为了地球母亲！开干！ 技术选型很简单。既然要节能减排，那么就将它贯彻到底，在保障开发体验的前提下怎么小怎么来。自然动辄几百K包体的React是不必考虑了，
你现在有一个包含许多软件包的单体仓库。你的公用组件包引入了一个第三方组件包（假设是antd），你的两个客户端包和也引入了antd，当然也引入了公用组件包。你在中使用了第三方组件包中的一个Context的Provider（假设你在做一个多端的React应用），你把代码在包下的这个Context的Consumer嵌套在这个Provider的下边。正常来讲，这个Consumer应当能够读到Provider提供的Context值。bug出现了，这个Provider并没能读到Context的值，就好像它的父级根本没有Provider一样。然而同样的代码在中就跑的通，这是为什么呢？ 今天这篇文章将会讲述一件由pnpm的依赖解析机制引发的问题。pnpm解决了安装npm包的许多痛点，然而其一些安装策略有可能会导致一些奇怪的行为，并且一时间很难发现。如果你还不知道pnpm是啥，
Photo by Alex Kubsch on Unsplash 雪猫社从来都少不了折腾。 先是雪先生要求加的表情包FacePack，然后又为了精确统计浏览量连了GA桑的API。之后，因为小图片不能放大看，又加了点击放大图片（Sakurairo里面更喜欢叫灯箱）的simple-img-modal，还为了显示EXIF加了EXIF读取功能。而驱动这些的，自然是前端脚本。 最开始雪猫社的这些附加组件都使用了React作为框架，现在回头看，这并不是一个很匹配我们的使用场景的选择，最直接地体现在React框架给我们带来的重达100kb的额外脚本上。这个大小的脚本会严重地拖慢我们的脚本解析速度，带来性能影响。但其实这也是当时无奈的折中之选：与React 16.x同期的Vue 2.6.x 包大小也要90多近100KB，虽然比React可能小20/30k左右，
登录