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
Currently non-semver version specifiers simply act as an override. This is not how npm handles it.
When faced with this situation, npm would pull the package.json from the specified location (git, GitHub, or local path), and continue dependency resolution as normal. At this point, its treated as a plain ol' locked down version specifier.
Logically, this is looking like:
incoming;// The incoming version specifiercurrent;// The current version specifier, a reference like a git urlletcurrentVersion=magicPackageJsonGetMethod(current).version// Valid version numberif(validVersion(currentVersion)){// Incoming is semver or versionif(isSemverOrVersion(incoming){// Check for conflictif(!inRange(currentVersion,incoming)thrownewException('Conflict')}elseif(/*Another reference like a git url (╯°□°)╯︵ ┻━┻*/){letincomingVersion=magicPackageJsonGetMethod(incoming).versionif(validVersion(incomingVersion)){// Check for conflictif(!inRange(currentVersion,incomingVersion)thrownewException('Conflict')}else{// Version not defined or not a real version value. (╯°□°)╯︵ ┻━┻}}}else{// Version not defined or not a real version value. (╯°□°)╯︵ ┻━┻}
Hardest part in this should be handling the discovery of the package.json's. For later reference, these pointers should help.
Git urls always have the protocol included. Identifying these should simply involve a isURL check of some kind. Or maybe some protocol check, since this can include @. Taking a peak at the npm source might help on this one.
GitHub urls can look really similar to a folder path, which isn't actually much of a problem.
Local paths always have file: before the actual path.
IMPORTANT: Addressing this changes behavior in a backwards incompatible way. A major version bump will be required to release this.
The text was updated successfully, but these errors were encountered:
Currently non-semver version specifiers simply act as an override. This is not how npm handles it.
When faced with this situation, npm would pull the
package.json
from the specified location (git, GitHub, or local path), and continue dependency resolution as normal. At this point, its treated as a plain ol' locked down version specifier.Logically, this is looking like:
Hardest part in this should be handling the discovery of the
package.json
's. For later reference, these pointers should help.isURL
check of some kind. Or maybe some protocol check, since this can include@
. Taking a peak at the npm source might help on this one.file:
before the actual path.IMPORTANT: Addressing this changes behavior in a backwards incompatible way. A major version bump will be required to release this.
The text was updated successfully, but these errors were encountered: