0

所以我已经阅读了npm upgrade#caret dependencies的文档。但npm upgrade似乎对我不起作用。这可能与github包有关。更新失败的包是我们内部 github 包 repo 中的一个包。

这是我的 package.json

{ 
  <snip>
 "devDependencies": {
    "@1uphealth/build-lifecycle-scripts": "^0.0.0",
    "@types/jest": "^25.2.2",
    "jest": "^26.0.1",
  },
  "dependencies": {}
}

但要求升级无济于事。

% npm ls --depth=0                                            
@1uphealth/core-example-lib@0.0.0
├── @1uphealth/build-lifecycle-scripts@0.0.0
├── @types/jest@25.2.3
└── jest@26.1.0

% npm upgrade --only=dev
<nothing happens>                                     
% npm upgrade --only=dev @1uphealth/build-lifecycle-scripts
<nothing happens>

但是，显式安装 0.0.1 版本可以正常工作...

% npm install '@1uphealth/build-lifecycle-scripts@^0.0.1'
+ @1uphealth/build-lifecycle-scripts@0.0.1
updated 1 package and audited 585 packages in 3.514s
<snip>
% npm ls --depth=0                               
@1uphealth/core-example-lib@0.0.0 /Users/marvin/git/internal/components/0.x/core-example-lib
├── @1uphealth/build-lifecycle-scripts@0.0.1
├── @types/jest@25.2.3
└── jest@26.1.0

这是我的.npmrc

@1uphealth:registry=https://npm.pkg.github.com/1uphealth

那么应该npm update更新这个安装吗？这看起来像是github packages存储库实现中的一些问题吗？或者，我做错了什么？

4

1 回答 1

1

好的。所以仔细阅读，npm-semver的文档caret ranges解释了这一点。我读过那个页面，但认为关于“主要”、“次要”、“补丁”的基本规则是我刚刚理解的——主要版本是破坏性的，次要版本是对 API 的兼容添加，而补丁是修复/不影响 API 的更改。但是这句话

允许不修改 [major, minor, patch] 元组中最左边的非零数字的更改

解释说它更微妙。基本结果是，对于0主要版本，次要版本被视为重大更改。因此，虽然^1.0.0将允许（满足）1.1.0并且^2.0.0将允许2.1.0，^0.0.0但实际上不会允许其他任何东西，而 '^0.1.0' 将只允许^0.1.[0-9]*.

基本上（大部分）次要版本“成为”主要版本。因此，基本原理是，对于0主要版本，许多版本将进行重大更改，这允许在不强制1.x发布的情况下完成（这表明组件的一定成熟度可能没有保证。）

于 2020-07-13T22:38:20.113 回答