UD5工具箱
常见问题解答
package.json 中哪些字段是必填的？
根据 npm 的规范，package.json 中只有两个字段是严格必填的：name 和 version。name 字段定义了包的名称，必须符合 npm 的命名规范（全小写、无空格、无大写字母、可以包含连字符和 scoped 前缀）。version 字段定义了包的版本号，必须遵循语义化版本号格式（MAJOR.MINOR.PATCH）。虽然其他字段都不是强制要求的，但强烈建议配置 description、main、scripts、author、license 等字段，它们对于项目的可维护性、可发现性和团队协作非常重要。缺少这些字段不会阻止 npm 发布，但会影响包的质量评分和用户体验。
语义化版本号中 ^ 和 ~ 有什么区别？
波浪号（~）只允许补丁版本（PATCH）级别的更新。例如 "~1.2.3" 等价于 ">=1.2.3 <1.3.0"，即安装 1.2.3 到 1.2.x 系列的最新版本。插入号（^）允许次版本（MINOR）级别的更新。例如 "^1.2.3" 等价于 ">=1.2.3 <2.0.0"，即安装 1.x.x 系列的最新版本。对于 0.x.x 版本，插入号的行为更保守："^0.2.3" 等价于 ">=0.2.3 <0.3.0"。星号（*）匹配任意版本。理解这些符号对于避免依赖冲突和意外升级至关重要。
dependencies 和 devDependencies 应该如何选择？
判断一个依赖应该放在 dependencies 还是 devDependencies 中的标准是：如果这个依赖在生产环境中运行时需要，就放在 dependencies 中；如果只在开发、测试、构建阶段需要，就放在 devDependencies 中。例如，React 是运行时需要的，应该放在 dependencies 中；而 Jest 测试框架、ESLint 代码检查工具、Webpack 构建工具等只在开发阶段使用，应该放在 devDependencies 中。此外，TypeScript 的类型声明包（@types/*）通常也放在 devDependencies 中。合理分类依赖可以减小发布包的体积，提升安装速度，并避免将不必要的开发工具暴露给使用者。
name 字段有哪些命名规则？
npm 包的 name 字段必须遵循以下规则：全部使用小写字母；不能包含空格；不能包含大写字母；可以使用连字符（-）和数字；不能以点（.）或下划线（_）开头；长度不能超过 214 个字符（包含 scoped 前缀）。对于 scoped 包，格式为 @scope-name/package-name，scope 名称同样必须遵循上述规则。不能使用以下保留名称：node、js、http、https 等。建议选择一个简洁、有描述性且不与已有流行包重名的名称。可以通过 npm view package-name 检查名称是否已被占用。
scripts 字段有哪些最佳实践？
scripts 字段的最佳实践包括：第一，始终定义 test 脚本，即使只是输出一条提示信息，因为 npm install 会自动执行 test 脚本。第二，利用 pre 和 post 生命周期钩子，例如定义 prebuild 来执行代码检查，定义 postbuild 来执行文件压缩。第三，使用 -- 分隔符传递参数给脚本，如 npm test -- --coverage。第四，对于复杂的构建流程，考虑使用 cross-env 等工具来处理跨平台的环境变量。第五，保持脚本名称简洁且语义化，如 build、dev、lint、test、deploy 等。第六，避免在脚本中硬编码路径，使用相对路径或环境变量。
如何检查项目中过时的依赖？
检查过时依赖有多种方法：第一，使用 npm 内置命令 npm outdated，它会列出所有有更新可用的依赖包，显示当前版本、期望版本和最新版本。第二，使用 npx npm-check-updates 工具，它可以更直观地显示所有可更新的依赖，并支持自动更新 package.json 中的版本号。第三，使用 GitHub 的 Dependabot 或 Snyk 等自动化工具，它们可以在依赖有安全更新时自动创建 PR。第四，定期运行 npm audit 检查已知的安全漏洞。建议每周或每月定期检查一次依赖更新，在确保兼容性的前提下及时升级到最新版本。
本工具的检查范围和局限性是什么？
本工具的检查范围包括：JSON 语法正确性、name 和 version 必填字段存在性、name 字段命名规范、version 字段语义化版本号格式、description/license/author/repository/main/scripts/dependencies/devDependencies/engines/keywords 等字段的存在性和基本格式。本工具的局限性在于：它只检查 package.json 本身的规范性，不会验证依赖包是否真实存在于 npm 仓库中，不会检查依赖包的版本是否存在兼容性冲突，也不会验证 scripts 中的命令是否能在当前环境中正常执行。对于这些更深层次的检查，建议结合 npm install、npm audit 等命令行工具使用。