You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 18, 2021. It is now read-only.
So I've looked through the number of previous similar issues (#65, #58, #48) raised regarding enforcing that tags for git repos need to be a v followed by a valid semver. I understand that you're trying to align with what npm is doing.
My issue is this: if I want to use some library from GitHub that uses git tags to mark releases and they don't include a v in front, I'd like to be able to give the library's address followed by a # followed by a tag. Not a semver range, not even necessarily a valid semver, but the exact tag name (e.g. 1.2.3, patch-1, 2015).
As far as I can see, under this scenario there's no reason to require the "v," use semver, or even consider the commitish to be a "version" since it's specifying a specific tag (or even commit hash). Is there any way to bypass these validations in this scenario? Or would the point raised in #48 about needing to support npm ls block this? #58 suggests using npm-shrinkwrap --warnOnNotSemver, which seems like it's the default because right now I'm only getting warnings not errors. But then it sounds like maybe #54 effectively turned those warnings into errors now so they stop execution?
Without these validations removed, I'm left with the choice of forking the libraries just to give add new tags or forking uber/npm-shrinkwrap to revise the behavior (if that's even possible). I really would rather not do either, but forking one library's easier than forking 10.
The text was updated successfully, but these errors were encountered:
Perhaps just for context I'll add that I'm trying to use npm and npm-shrinkwrap for frontend dependencies. On my node.js backend, npm-shrinkwrap is working perfectly. Using it for frontend dependencies on the other hand.....it's the wild west!
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
So I've looked through the number of previous similar issues (#65, #58, #48) raised regarding enforcing that tags for git repos need to be a v followed by a valid semver. I understand that you're trying to align with what npm is doing.
My issue is this: if I want to use some library from GitHub that uses git tags to mark releases and they don't include a v in front, I'd like to be able to give the library's address followed by a # followed by a tag. Not a semver range, not even necessarily a valid semver, but the exact tag name (e.g.
1.2.3
,patch-1
,2015
).Here's some examples:
As far as I can see, under this scenario there's no reason to require the "v," use semver, or even consider the commitish to be a "version" since it's specifying a specific tag (or even commit hash). Is there any way to bypass these validations in this scenario? Or would the point raised in #48 about needing to support
npm ls
block this?#58 suggests using
npm-shrinkwrap --warnOnNotSemver
, which seems like it's the default because right now I'm only getting warnings not errors. But then it sounds like maybe #54 effectively turned those warnings into errors now so they stop execution?Without these validations removed, I'm left with the choice of forking the libraries just to give add new tags or forking uber/npm-shrinkwrap to revise the behavior (if that's even possible). I really would rather not do either, but forking one library's easier than forking 10.
The text was updated successfully, but these errors were encountered: