Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add minVersion function #208

Closed
wants to merge 1 commit into from
Closed

Conversation

kellyselden
Copy link

I'm trying to decide which range is "newer" when automatically updating package.json here and here. The scenario is

  • my dep is "a": "^2.0.2"
  • upstream was updated "a": "^1.4.0" => "a": "^2.0.0"

I want to be smart and say, even though the dep was updated, mine is more recent, so ignore the change. My pseudocode is if myDepRange < newDepRange then update.

Getting the lowest possible version in a range seems like a good way to compare two ranges for newest. I currently am doing:

function minVersion(range) {
  return new Range(range).set[0][0].semver.version;
}

But I feel like I'm reaching into too much private API. I would like add this function upstream to this library.

@coveralls
Copy link

coveralls commented Sep 11, 2017

Coverage Status

Coverage increased (+0.02%) to 98.045% when pulling 1e13894 on kellyselden:minVersion into ec6f97a on npm:master.

@jaydenseric
Copy link

I would really like this too, to be able to derive the minimum supported Node.js version from the range in package.json engines. This is useful for configuring @babel/preset-env to transpile and polyfill for the minimum supported Node.js version.

To easily do this in my own packages I make the assumption the range is always a single semver prefixed with >=, so I can just strip it off with substring(2) to get a min version.

@babel/preset-env will eventually look at engines.node to do this automatically, so a more robust solution that can take arbitrary, complicated ranges will be useful.

if (!rangeObj.range) {
return '0.0.0';
}
return rangeObj.set[0][0].semver.version;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will return an incorrect value in the following cases:

minVersion('1.2.3 || 1.0.0') // expect 1.0.0, get 1.2.3
minVersion('<=1.2.3 >1.0.0') // expect 1.0.1, get 1.2.3
minVersion('>1.2.3') // expect 1.2.4, get 1.2.3
minVersion('>1.2.3-alpha') // <-- this one is probably impossible? 1.2.3-alpha is incorrect tho

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was working on a patch for this before I saw this PR. #241 deals with these edge cases and includes testing for them situations. minVersion('>1.2.3-alpha') is not impossible, I believe the correct result is 1.2.3-alpha.0 which is less than 1.2.3-beta.

@isaacs
Copy link
Contributor

isaacs commented Feb 2, 2018

I think that this might be theoretically impossible. You could get the minimum of a given set of versions that satisfies a given range. But what you can't do is (usually) specify the minimum version that would satisfy a range. Consider >1.2.3-alpha which would be satisfied by 1.2.3-beta or 1.2.3-alpha.0 or 1.2.3-alphb.

@jaydenseric
Copy link

The no-unsupported-features rule of eslint-plugin-node would probably benefit from this too. It seems they changed their approach from attempting to determine a min version.

@coreyfarrell
Copy link
Contributor

semver.minVersion was implemented by #241 and released in [email protected]. Sorry for bypassing this PR, I created/submitted the patch before I saw this.

@isaacs isaacs closed this May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants