- 主题:[转载]两行代码构成的 npm 包影响到了数百万项目
设计本意没错，但是实际情况是很多包依赖都是依赖最新的。结果导致出现新的问题。比如向后兼容问题。
所以固定有固定的好处。
而且我就喜欢固定的，这样我能明确知道我依赖的版本。
而且我也奇怪为啥mvn不学习一下，这种功能很简单。
但是我希望永远不要学习这种先进的包管理。
【 在 eGust 的大作中提到: 】
: 这可真把我逗乐了
: java 这么成熟，为啥包管理都学 ruby 不学 java 啊？windows 没有9是因为谁啊？
: 知道 semver 是啥意思么？作为 boilerplate 项目，不锁版本版本号的目的很明显，创建新项目的时候能自动获得最新的安全补丁，而不用担心功能受影响。而且实际中的情况也是，对于依赖复杂的项目，隔一两个月跑一次 yarn audit/npm audit，肯定会有大量的安全警告，并且 upgrade 正常情况下可以保证获取新版本修复安全隐患
: ...................
--
修改:littleSram FROM 124.64.19.*
FROM 124.64.19.*
mvn是用snapshot解决这个问题
永远拉取最新实现
胆肥的话，mvn版本号也能按区间匹配永远拉最新的
【 在 littleSram (littleSram) 的大作中提到: 】
: 设计本意没错，但是实际情况是很多包依赖都是依赖最新的。结果导致出现新的问题。比如向后兼容问题。
: 所以固定有固定的好处。
: 而且我就喜欢固定的，这样我能明确知道我依赖的版本。
: ...................
--
修改:oldwatch FROM 180.169.205.*
FROM 180.169.205.*
【 在 littleSram (littleSram) 的大作中提到: 】
: 设计本意没错，但是实际情况是很多包依赖都是依赖最新的。结果导致出现新的问题。比如向后兼容问题。
~~~~~~~~~~~~~~~~~~~~~~~~从未见过这样的。
最常见的是^，就是在保证没有breaking change的前提下最新。没见过无脑最新的。
js社区依赖出问题，基本都是不遵守semver语义，导致^下也出现了breaking change，或者干脆就是缺乏测试出了bug。讲道理大多数不是包管理逻辑的问题，而是社区开发质量普遍不高的问题。
: 所以固定有固定的好处。
: 而且我就喜欢固定的，这样我能明确知道我依赖的版本。
: ...................
--
FROM 223.72.67.*
您说的是。snapshot确实是默认最新。
版本区间我确实没用过。
【 在 oldwatch 的大作中提到: 】
: mvn是用snapshot解决这个问题
: 永远拉取最新实现
: 胆肥的话，mvn版本号也能按区间匹配永远拉最新的
: ...................
--
FROM 124.64.19.*
是，这是根本原因。
【 在 beep 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~从未见过这样的。
: 最常见的是^，就是在保证没有breaking change的前提下最新。没见过无脑最新的。
: js社区依赖出问题，基本都是不遵守semver语义，导致^下也出现了breaking change，或者干脆就是缺乏测试出了bug。讲道理大多数不是包管理逻辑的问题，而是社区开发质量普遍不高的问题。
: ...................
--
FROM 124.64.19.*
[1.0,2.0)
[]包含，（）不包含
不过说实话真用起来无穷的坑，因为会影响默认的版本冲突/适配逻辑
最多是在全局顶层pom定义一下防止下面的具体定义太自由发挥
【 在 littleSram (littleSram) 的大作中提到: 】
: 您说的是。snapshot确实是默认最新。
: 版本区间我确实没用过。
--
FROM 180.169.205.*
使用者这么多，发布的时候都不仔细测试一下吗
【 在 hgoldfish 的大作中提到: 】
:
: 一个 npm 小项目的更新给整个 npm 生态系统制造了一场混乱，影响到了数百万 JS 项目。名叫 is-promise 的库包含了两行代码，其它项目可通过一行代码调用使用该库。它的功能是让开发者测试一个 JS 对象是否是 Promise。
:
: 尽管这个库只有两行代码，但它却是最流行的 npm 包之一，被超过 340 万个项目使用。
:
: 上周末 is-promised 释出了一个更新，结果由于它不符合正确的 ES 模块标准，导致使用该库的其它项目在构建时出错。问题并没有导致现有 JS 项目崩溃，而主要无法编译新版本。
:
: 许多知名的 JS 项目都受到影响，其中包括 Facebook 的 Create React App，Google 的 Angular.js 框架，Google 的 Firebasse-tools，亚马逊的 AWS Serverless CLI，Nuxt.js 等等。npm 生态系统的依赖问题早在 2016 年就引发过广泛关注。
:
:
https://www.zdnet.com/article/another-one-line-npm-package-breaks-the-javascript-ecosystem/ :
: --
: 灭绝人性啊
:
:
发自「今日水木 on iOS」
--
FROM 123.125.37.*
能举个具体的例子出现过啥问题么？
说实话我真的挺好奇的，作为本版最经常忽悠 js 技术，开个 electron 项目算是家常便饭，还玩过 react native 的人，我试过的各种不成熟的库的机会应该比你们都多。为啥我这种经常在河边走的从来没掉坑里，反倒是你们连 lock 原理都搞不清的动不动就掉坑里？
【 在 littleSram (littleSram) 的大作中提到: 】
: 设计本意没错，但是实际情况是很多包依赖都是依赖最新的。结果导致出现新的问题。比如向后兼容问题。
: 所以固定有固定的好处。
: 而且我就喜欢固定的，这样我能明确知道我依赖的版本。
: ...................
--
FROM 115.188.68.*
根据 semver 语义，2.0.0-alpha 属于这个区间么？
貌似 2.0.0-alpha < 2.0.0
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: [1.0,2.0)
: []包含，（）不包含
: 不过说实话真用起来无穷的坑，因为会影响默认的版本冲突/适配逻辑
: ...................
--
FROM 113.201.131.*
按这个文档 -qualififer段落，不存在优先于存在
https://cwiki.apache.org/confluence/display/MAVENOLD/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])
For ordering, the following is done in order until an element is found that are not equal:
numerical comparison of major version
numerical comparison of minor version
if revision does not exist, add ".0" for comparison purposes
numerical comparison of revision
if qualifier does not exist, it is newer than if it does
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
case-insensitive string comparison of qualifier
* this ensures timestamps are correctly ordered, and SNAPSHOT is newer than an equivalent timestamp
* this also ensures that beta comes after alpha, as does rc
if no qualifier, and build does not exist, add "-0" for comparison purposes
numerical comparison of build
【 在 KDr2 (R2D2) 的大作中提到: 】
: 根据 semver 语义，2.0.0-alpha 属于这个区间么？
: 貌似 2.0.0-alpha < 2.0.0
--
FROM 180.169.205.*