重写计划

本篇文章是前端工具链系列文章的开篇之作，本来是打算写一篇很长很长的文章，来详尽阐述2023年的前端工具链的全貌的。但奈何篇幅实在太长，不便发布和阅读，而且有些部分完成度已经较高，但由于其他部分的完成度几乎为0导致这些内容不能发布出来 （可以预见的由于工作原因另一部分可能拖更较久） 。

最终选择了分段分章节的形式，将每个部分单独提出来说，最终在一个目录中汇总，这样阅读体验更好，每个部分也能说得更详细一点。

本篇主要讲述npm的发展历史（历史渊源和各个版本的改动），组织node_modules方式的变动以及package.json的详细介绍（并发布一个自己的npm包）；除此之外，还会介绍node官方提出的现代包管理器愿景，并介绍corepack工具（包管理器的管理器）。

<!-- more -->

npm(Node Package Manager) 不仅是一个包管理器，更是前端的项目管理器，它除了管理依赖，还定义了项目的信息、脚本和行为，这些信息都被npm存储在package.json中。 可以说npm是一切前端项目，包括其他包管理器的基础，其他包管理器均必须实现npm的基础功能，你可以没有其他包管理器，但你必须有且理解npm。

上面一段是我在 上面一段是我在 《前端工具链》**《前端工具链》 草稿中写的原文，虽然这一段在新的组织形式下已经不再合适作为部分总结，但仍很好地概括npm的地位——理解了npm你才能理解其他包管理器（或者说为什么需要更现代的解决方案），也是为什么我们已经有yarn和pnpm等更现代的解决方案，连node官方都打算不再完整内置npm的今天我们仍需要学习npm的原因，而不仅仅是出于一些兼容性的原因才学习和使用npm（当然学习了npm的机制也能更好地解决出现在其他包管理器中出现的兼容性问题）。 草稿中写的原文，虽然这一段在新的组织形式下已经不再合适作为部分总结，但仍很好地概括npm的地位——理解了npm你才能理解其他包管理器（或者说为什么需要更现代的解决方案），也是为什么我们已经有yarn和pnpm等更现代的解决方案，连node官方都打算不再完整内置npm的今天我们仍需要学习npm的原因，而不仅仅是出于一些兼容性的原因才学习和使用npm（当然学习了npm的机制也能更好地解决出现在其他包管理器中出现的兼容性问题）。

npm的诞生

如果你用过C++，也用过Python或者Rust，那你在 如何快速地调用他人写好的代码 这件事上，对二者的效率有深刻的认识。是的，Python/Rust有自己的包管理器（pip/cargo），但C++却没有一个统一的包管理器方案（vcpkg或许是一个选择），这导致你调用别人代码的门槛显著提高，也不利于库作者的版本管理。

程序员群体从最初开始就强调一个社区文化、开源精神 程序员群体从最初开始就强调一个社区文化、开源精神 （Bill Gates除外）（Bill Gates除外） ，复用别人的代码和让别人能复用自己的代码自然也是社区的头号需求，在现代前端开发中node环境已经普及的今天（或者说昨天），一个对应node环境的包管理器自然会产生，是的，这就是npm。 ，复用别人的代码和让别人能复用自己的代码自然也是社区的头号需求，在现代前端开发中node环境已经普及的今天（或者说昨天），一个对应node环境的包管理器自然会产生，是的，这就是npm。

拿Python作对比的话：JavaScript是语言本身，类似于python；node是语言运行环境，类似于cpython；npm是包管理器机制，类似于pip（和PyPi）。 其实在项目管理这一点上，node.js和npm更像Rust于Cargo的关系 但是说爸爸像儿子总是不合适的

前npm时代如何共享代码

毕竟JS和Web的历史远比Node和npm更悠久，那么在更为原始的web开发年代，大家是如何共享代码的呢？

对于直接使用代码来说，有两种方法：

JS模块化