npm_time_machine

NPM Time Machine - Move package.json through the time!

Usage: npm_time_machine [OPTIONS] <DATE>

Arguments:
  <DATE>  Target date (format: DD-MM-YYYY)

Options:
  -f <INPUT_FILE>       input file [default: package.json]
  -o <OUTPUT_FILE>      output file [default: package.json.out]
      --no-cache        Don't use / reload cache
      --silent          Silent mode
      --dry-run         Dry run - show changes only
  -h, --help            Print help (see more with '--help')

描述

npm_time_machine 是一个 package.json 的“时间点”锁定工具。给定日期，它会将 package.json 锁定与最新稳定版本的库进行比较，并使用更新的版本。

预期用途是二分日期，以找到可以管理的升级点。例如，通过避免多个核心库发生变化的场景。

解决示例

package.json:

• 包 A - 版本 1.0.0
• 包 B - 版本 1.0.0

状态在： 01-01-2020

• 包 A - 版本 0.5.0
• 包 B - 版本 1.1.0

针对 01-01-2020 的解决状态

• 包 A：版本 1.0.0 （package.json 有比目标日期更新的版本）
• 包 B：版本 1.1.0 （目标日期有更新的版本）

理由

• 基于 Node 的项目倾向于在库之间建立依赖网络
• 流行的库大约每 1-3 年引入一个主要版本，需要代码重写，有时非常复杂
• 在前端项目中跳过升级可能是一个可行的选项
• 随着时间的推移，由于库之间的相互关联，升级变得越来越困难，一个库的升级可能会拖累其他库
• 当项目足够大并且仍在开发中时，
  • 不可能停止开发过程进行升级
  • 很难确保安全性和稳定性（尤其是测试库也可能需要升级）
  • 几乎不可能有可审查的 PR

合理的敏捷解决方案是将升级分成多个“检查点”。

每个检查点都足够小且稳定，可以合并到代码库中，可以在数月内逐步完成全面升级，而不会中断进度。

由于我没有找到这样的工具，所以我决定自己编写。

演示

注意事项/已知问题

• 时间机器缓存创建在 cwd - 可能会污染dirtree
• devDependencies 不会被处理
• 仅支持单一日期格式
• 由于测试输入有限，可能存在处理盲点
• 未在固定非稳定版本（RCs、alpha、beta等）上测试