Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/node.js/38.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181

Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/google-app-engine/4.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Node.js 更新npm包的自述文件时出现版本冲突?_Node.js_Npm - Fatal编程技术网

Node.js 更新npm包的自述文件时出现版本冲突?

Node.js 更新npm包的自述文件时出现版本冲突?,node.js,npm,Node.js,Npm,如果我修改了我维护的npm包的自述文件,我是否需要在package.json中升级版本并进行另一次npm发布?或者有没有其他方法可以在不增加版本号的情况下更新自述文件。npm publish——如果注册表中已经存在版本号,则force将覆盖自述文件 根据您对“需要”的定义,这可能是两个截然不同的问题: [在不影响版本号的情况下发布自述文件更改可以吗?] [在技术上是否可以在不增加版本的情况下发布更改] 接受的答案(通过npm publish--force更新,即不增加版本号的任何部分)是对第二季

如果我修改了我维护的npm包的自述文件,我是否需要在package.json中升级版本并进行另一次npm发布?或者有没有其他方法可以在不增加版本号的情况下更新自述文件。

npm publish——如果注册表中已经存在版本号,则force将覆盖自述文件


根据您对“需要”的定义,这可能是两个截然不同的问题:

  • [在不影响版本号的情况下发布自述文件更改可以吗?]

  • [在技术上是否可以在不增加版本的情况下发布更改]

  • 接受的答案(通过
    npm publish--force
    更新,即不增加版本号的任何部分)是对第二季度的一个好答案。但我想谈谈Q1

    不鼓励使用
    npm publish--force
    。相反,鼓励作者使用,其中规定:

    。。。X.Y.Z的版本格式(主要.次要.补丁)。错误无法修复 影响API增量的补丁版本,向后兼容 API添加/更改会增加次要版本,并向后增加 不兼容的API更改会增加主版本

    因此,我的答案是: 虽然从技术上讲,有一种方法可以在不增加版本的情况下发布更改,但您不应该这样做。对于不影响软件包API的较小编辑,应将“补丁”版本升级,例如从1.2.0升级到1.2.1

    你能做的最好的事情是: 发布新的次要版本:

    npm publish [@<scope>/]<name>[@<your new minor version>]
    
    npm发布[@/][@]
    
    请参见此处的详细讨论:


    以下是不鼓励(!)的,不应该是您的第一选择
    执行此操作时要小心,取消发布包后,直到24小时后,它才允许您重新发布包

    您可以取消发布包,将该版本保留为空(但在执行此操作之前请理解其含义):
    npm unpublish[@/][@]


    注意:
    --force
    参数已被弃用。

    适用于在此处着陆并认为自己做得对的其他人。是的,你做得对;在5-10分钟内查看您的
    npm
    页面。

    好的,我就是这么想的。对于自述文件的更改,我应该只使用bump minor。force现在不推荐使用键入错误或向自述文件添加信息。md(或文档)不应该引起修补程序bump。没有任何代码被更改,只有文档。问题仍然存在于特定版本中。当然,你可以不推荐这个软件包,但这似乎是一个很糟糕的方法。由于publish--force现在已经被弃用,我想唯一的办法就是实际升级补丁。就这一点而言,我认为NPM应该允许在不升级补丁的情况下对README.md进行更改。README.md是一个特殊的案例文件,因为NPM有义务在网站上提供该文件以供文档使用。因此,它可以被视为“meta”,就像包中没有其他文件一样。如果不清楚,npm的文档说明“即使包版本未发布,特定的名称和版本组合也不能重用。为了再次发布包,必须使用新的版本号。”。这本质上意味着,在没有补丁包的情况下,取消发布和重新发布并不是更新文档的一个解决办法。在执行此操作时要小心,取消发布包后,直到24小时后才允许重新发布。