[!info] related notes

• 库构建中 JS 打包与 DTS 生成分层

Library&Package

学习笔记：Library、Package 与 Monorepo 架构解析

1. 核心概念辨析：Library vs Package

在软件工程中，“包”和“库”有着明确的侧重点：

• Library（库）—— 侧重“功能与复用”
  • 定义：预先写好的、可复用的代码集合（函数、类、接口等）。
  • 作用：提供特定功能供开发者在代码中主动“调用”。
  • 类比：工具箱里的螺丝刀或锤子。
• Package（包）—— 侧重“分发与组织”
  • 定义：包含代码（Library）及元数据（如版本号、配置文件 package.json）的分发单元。
  • 作用：方便通过包管理器（npm, pip 等）进行下载、安装和版本控制。
  • 类比：宜家商场里装着工具、零件和说明书的包装盒。

关于依赖（Dependency）： 别人发布的 Package 成为你项目的 Dependency（依赖），而你在代码中实际调用的是这个 Dependency 提供的 Library。

2. 前端生态中的实际映射

• Vue / React：通过 npm install 下载时，它们是 Package；在代码中 import { ref } from 'vue' 时，使用的是它的 Library 功能。
• package.json：该文件本身不仅定义了当前项目是一个独立的 Package，里面的 dependencies 字段也罗列了项目运行所需的外部 Packages。

3. Monorepo 架构中的子模块：是 Lib 还是 Package？

在 Monorepo（多包架构）中，子模块的身份取决于物理机制与逻辑意图的差异：

• 物理层面（全都是 Package）
  • 只要目录中包含 package.json，包管理器（如 pnpm, Yarn）就会将其视为独立的 Package，以此来处理依赖和工作区软链接。
• 逻辑与命名约定（packages/ vs libs/）
  • packages/ 目录：通常侧重于对外发布。例如开源项目将各个模块分别发版至 npm（如 @vue/reactivity）。
  • libs/ 目录：通常侧重于内部复用。例如企业内部业务项目中，供不同 App 共享但永远不会发布到公网的 UI 组件或工具函数（如 shared-ui）。

4. 总结

“有没有 package.json” 决定了它物理上是不是一个 Package。我们安装的是 Package，在代码里写的是 Library。