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 a way to include all prerelease versions in a range #871

Open
acarl005 opened this issue Sep 3, 2022 · 7 comments
Open

Add a way to include all prerelease versions in a range #871

acarl005 opened this issue Sep 3, 2022 · 7 comments

Comments

@acarl005
Copy link

acarl005 commented Sep 3, 2022

Currently, prerelease versions can only be opted-in to for specific patch versions, e.g. the range ^3.0.0-0 will allow 3.0.0-beta.1, but not 3.1.0-beta.1. I think this is the optimal behavior for what most users expect. However, there are some use cases for allowing prereleases for everything in the range. For example, see this discussion. In this case, vite-node wraps vite and it lists vite in its dependencies. However, @sveltejs/kit also depended upon vite, but it needed a prerelease beta version. The result is that @sveltejs/kit and vite-node ended up with separate, incompatible versions, breaking my project. I ended up having to use overrides in my package.json to work around it.

It would be nice if there was a way for vite-node to specify a looser range that allows all prerelease versions.

Maybe it could be something like ^^3.0.0-0?

@ljharb
Copy link
Contributor

ljharb commented Sep 3, 2022

Can’t it do ^3.0.0-0 || ^3.1.0-0 etc, as needed?

@acarl005
Copy link
Author

acarl005 commented Sep 3, 2022

Yes, that is possible. However, it means that the maintainers of vite-node need to add a version with every minor release of vite, which is burdensome.

@ljharb
Copy link
Contributor

ljharb commented Sep 4, 2022

True, but that’s far less burdensome than updating the entire node ecosystem to support a new range operator.

@jwdonahue
Copy link
Contributor

This seems like a discussion for the node issues site. SemVer, does not currently define range specs, though that is a WIP, but it's primarily meant to document the most common factors between a small set of existing tools that each have their own range spec semantics.

@ljharb
Copy link
Contributor

ljharb commented Sep 16, 2022

Oh, my mistake, I thought this issue was filed on npm/semver. This spec doesn't have ranges at all, so I totally agree it's entirely off topic.

@sabrican3532

This comment was marked as off-topic.

@anafebacus

This comment was marked as spam.

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

No branches or pull requests

6 participants
@ljharb @acarl005 @jwdonahue @sabrican3532 @anafebacus and others