如何用JSPM锁定依赖树？为何jspm install仍出现浮动版本？

我来帮你拆解这个问题——这其实是JSPM 0.16版本的依赖解析逻辑和npm的lock机制之间的小冲突导致的，具体原因和解决办法如下：

1. JSPM 0.16的版本解析逻辑和你理解的不一样 #

JSPM官方文档提到的“重现config.js中的精确版本”，其实需要主动触发严格锁定模式，默认的jspm install行为并不是完全忽略package.json的版本范围：

• 当你执行无参数的jspm install时，它会先读取package.json里的版本范围（比如^5.0.6），然后拉取满足这个范围的最新兼容版本，之后再更新config.js里的记录。这就是你看到buffer@^5.0.6最终安装了5.1.0的原因——5.1.0符合^5.0.6的版本规则。
• config.js里的精确版本更像是JSPM的“安装历史记录”，而不是强制锁定的约束，默认情况下它不会阻止JSPM去拉取符合package.json范围的新版本。

2. package-lock.json对JSPM无效 #

JSPM 0.16是独立于npm的依赖管理工具，它不会读取npm的package-lock.json来确定依赖版本。npm的lock文件只对npm install生效，JSPM有自己的一套依赖解析和锁定逻辑，也就是config.js，但这个逻辑需要你手动开启严格模式。

3. 解决办法：强制JSPM严格遵循config.js的精确版本 #

如果你想完全重现config.js里的锁定版本，需要在执行安装时加上--lock参数：

jspm install --lock

这个参数会告诉JSPM：忽略package.json里的版本范围，直接使用config.js中记录的精确版本进行安装，这样就不会再出现版本浮动的情况了。

另外，如果你希望每次新增依赖时都自动锁定精确版本，可以在安装依赖时加上--save-lock参数，这样JSPM会更新config.js的同时，确保后续无参数安装也能严格遵循这些版本：

jspm install npm:buffer@5.1.0 --save-lock

额外提醒 #

JSPM 0.16是比较老旧的版本了，如果你有机会升级到JSPM 2.x，它的依赖管理逻辑会更贴近现代npm/yarn的lock机制，能减少这类版本解析的混淆问题。同时要确保config.js已经正确提交到版本控制，这样团队成员执行jspm install --lock时才能拿到一致的依赖版本。

内容的提问来源于stack exchange，提问作者Bob Arezina