Hi，我是 Sea，欢迎打开新一期的「每周菜谱」，这是第「04」期，发表于 2023-02-05，我们先来看看每周有什么值得推荐的

Hi，我是 Sea，欢迎打开新一期的「每周菜谱」，这是第「03」期，发表于 2023-01-30，我们先来看看每周有什么值得推荐的

今天来讲讲我为什么会想到更换图床，GiuHub —> 阿里云 OSS

Hi，我是 Sea，欢迎打开新一期的「每周菜谱」，这是第「02」期，发表于 2023-01-16，今天开始每周菜谱的第一期内容，我们先来看看每周有什么值得推荐的

Hi，我是 Sea，欢迎打开新一期的「每周菜谱」，这是第「01」期，发表于 2023-01-16，今天我们不讲菜谱，先来介绍下有哪些优秀的前端周刊

Hi，我是 Sea，欢迎打开新一期的「每周菜谱」，这是第「00」期，发表于 2023-01-16，今天我们不讲菜谱，先来介绍下「每周菜谱」

随着时间的推移，Git 存储库变得越来越大，或者自己误操作，把 node_moduoles、.yarn、.DS_Sore 这种大文件上传到远程仓库中，虽然后期把他们移除了，但还是会使仓库体积变大，获取仓库变得更慢，每个人都必须下载文件，因此我们需要缩减 Git 仓库体积。

今日打算重新组装系统，因此需要从零开始安装在 Mac 上的必备的一些软件。

背景

随着时间的推移，项目中 package.json 中的依赖越来越臃肿，安装依赖的速度越来越慢，各种奇奇怪怪的包，不一定都会用到，因此我们可以为项目减负，使用 depcheck 检测项目中不用的依赖包，然后移除它们。

背景

当一个公共依赖包的使用者数量逐渐庞大的时候，如何保证当此包发布新版本时，所有使用者都能尽可能快地得到更新？或者如何保证自己仓库的使用的第三方库一直保持安全情况下的最新状态呢？