npm 版本号和 scripts 习惯应该早点养成

npm 真正开始好用之后，开发者很快就会遇到两个新问题：依赖到底应该装哪个版本，项目命令又该怎么统一。它们看起来像细节，但在 2013 年已经足够决定一个项目是“能复现”还是“只能在作者电脑上运行”。

版本号不是随便写一个数字

当项目开始引用越来越多的包时，如果没有明确版本范围，很容易今天能跑、明天装出来就不一样。哪怕刚开始不深入研究所有语义规则，也至少应该意识到：依赖版本是项目环境的一部分，不是可有可无的备注。

scripts 能把命令入口收拢起来

很多项目最初会在文档里写一堆命令：“先执行这个，再执行那个。”一旦步骤多了，协作成本马上上升。把常用动作放进 scripts，就能让大家都从统一入口启动。

{
  "scripts": {
    "start": "node app.js",
    "test": "node test.js"
  }
}

这样做的好处是，后来不管启动命令怎么变，对外入口依然还是 npm start、npm test。

项目习惯越早统一越省事

2013 年很多 Node.js 项目还在快速摸索阶段，所以更容易出现每个人都按自己习惯操作的情况。有人直接 node server.js，有人写 shell 脚本，别人接手时常常看不懂。把版本和 scripts 这两个点早点统一，项目就会稳定很多。

别等项目变大了再补

这类习惯最容易被拖延，因为一开始看不出问题。但等依赖多起来、成员多起来，再回头补版本和命令入口，成本就明显高了。越早整理，收益反而越大。

小结

npm 在 2013 年的意义，已经从“能装包”继续往前走到了“能不能稳定协作”。把依赖版本和 scripts 当成项目基本面来维护，是那个阶段很值得早点建立的工程习惯。