I have dependencies in package.json like so:
<packageName1>: ^0.1.0,
<packageName2>: <url>,
<packageName3>: 5.1.0
Is there any way to check that "^0.1.0" and "5.1.0" are correct, but "< url >" is incorrect semver?
I used semver npm package but haven't seen any functionality to do so.
When referencing package by its url, you cannot specify any version; even if you do so, npm will ignore this.
Of course, you can do this manually: it's easy to read your package.json, parse out the semver constraint, get the version of your dependency (by reading its package.json) and finally using node-semver lib (or similar) to ensure, that the installed version is within range specified.
I used semver.validRange method instead of semver.valid
Related
For instance, say I have "foo: ^1.0.0" listed in my package.json and that project's released versions are [1.0.0, 1.1.0, 1.2.0, 2.0.0]. I want to find out what ^1.0.0 resolves to without installing or looking it up manually. Does a tool for this exist? I would expect it to be something like npm resolve foo#^1.0.0
Yes there is!
If you're using npm use view
npm view foo#^1.0.0
Otherwise you could use yarn with info
yarn info foo#^1.0.0
And in case you want even better statistics check out bundlephobia. It gives size estimations for the given version as well as the others and also an analysis of the exports.
I am getting problems like this when validating that the right version of a dependency is installed:
package with name csvtojson is not satisfied. Installed version: 0.4.5 desired version: github:Keyang/node-csvtojson#16ba2237e0bd96d6e3773e4c4d6e36c70efa620e
I am trying to use the semver package to validate a desired dependency version:
const semver = require('semver');
const satisfies = semver.satisfies(installedVersion, desiredVersion);
in package.json, we might see this:
"csvtojson": "^1.12.0"
or
"csvtojson":"github:Keyang/node-csvtojson#16ba2237e0bd96d6e3773e4c4d6e36c70efa620e"
what I want to do is determine if an installed dependency meets the version range of the desired dependency.
If the desired version is not semverish, I am willing to skip it, but I don't have a good test for that, anyone have a good idea how to skip desired versions that don't appear to be semverish?
Maybe use a regex like this:
/.*[0-9]{1,5}\.[0-9]{1,5}\.[0-9]{1,5}/
?
This RegExp here is validating all scenarios:
^(\d|[1-9]\d*)\.(\d|[1-9]\d*)\.(\d|[1-9]\d*)(-(0|[1-9A-Za-z-][0-9A-Za-z-]*|[0-9]*[A-Za-z-][0-9A-Za-z-]*)(\.(0|[1-9A-Za-z-][0-9A-Za-z-]*|[0-9]*[A-Za-z-][0-9A-Za-z-]*))*)?(\+[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$
Source: https://brunorb.com/untangling-semver/
The npm package for NW.js (package name "nw") has versions like this:
0.16.0-beta2sdk, 0.16.0-beta1sdk, 0.15.4, 0.15.4-sdk, 0.15.3, 0.15.3-sdk, 0.15.2, 0.15.2-sdk,...
I am currently using nw as a dependency in my package.json manifest, and I was wondering what version I need to specify to get "the latest version that ends with -sdk".
I have tried things like '*-sdk' and '0.x-sdk' but that didn't quite work as intended. I had a look at the syntax for semantic versioning but couldn't immediately find something for tags like this.
Anyone know if this can be done via semantic versioning syntax?
Thanks
You can add "latest" as the value in the packages.json file with the key being any package that you want to install like:
{
"package_name": "latest"
}
Im trying to figure out how npm versioning works because im getting stuck on two invalid packages. Ref my other question. The module i need, serialport, get these packages invalid, "readable-stream" and "string_decoder". Serialport have downloaded this version:
readable-stream#1.0.27-1
Serialports dependency is
"readable-stream": "~1.0.2"
Readable-streams available versions are:
....
'1.0.26',
'1.0.27-1',
'1.0.31',
....
Which explains why 1.0.27-1 is picked. Because of the tilde and ~1.0.2, meaning that these three numbers have to exist in each version. Ref Jakob Mattsson´s simple article
readable-stream downloads
string_decoder#0.10.25-1
readable-stream again depends on
"string_decoder": "~0.10.x"
And string_decoders available versions are
....
'0.10.24',
'0.10.25-1',
'0.10.25',
'0.10.31',
'0.11.10-1'
....
How come that version is downloaded? Ref the article again, tilde means that it has to has 0.10 in the version number, and x is whatever exists?
Why is not string_decoder#0.10.31 chosen?
I believe my problem in question is related to prereleases that this extra dash is called. Im trying to gather facts to maybe seem if dependencies can get updated.
I recieved an answere on github, issue answer, thought i would share it with the rest who might wonder:
semver range checking is done semantically, not lexically, so 1.0.31 should match with npm#2:
% semver -r '~1.0.2' 1.0.26 1.0.27-1 1.0.31 1.0.26 1.0.31 I suspect that the behavior you're seeing is due to a bundledDependency included in the package tarball.
See Node app fails to run because of prerelease for a more detailed answer too why this happens.
I get invalid packages installing, even if the installation is a success. Btw, this question is related to the answer - question about versioning
npm install serialport
These are packages which is stuck far in the dependency tree.
npm ERR! invalid: readable-stream#1.0.27-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream
npm ERR! invalid: string_decoder#0.10.25-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream/node_modules/string_decoder
This ends up causing this error in my browser:
Uncaught TypeError: Cannot read property '_ansicursor' of undefined
Is there any way to sort up in this npm problem? Can I avoid these prerelease packages?
The github answere below gave me a lot of insight into npm and I thought I had to dig somewhere else for the issue. But it acctually just seemed like serialport does not work very well, anymore, with browserify. It used to work because i used if for two months, but something changed. When im saying it out loud, it just sounds stupid anyway. So dont browserify serialport.
I recieved an answere on github, issue answere, thought i would share it with the rest who might wonder:
The change in handling prerelease versions in semver#4 is one of the primary motivators for the major version bump to npm#2. All versions of npm 2 are affected by this change, which, put briefly, ensures that all version information to the right of - in version strings is ignored when doing semver range matching. When you upgrade from npm#1 to npm#2, it's normal to see some irregularities show up when you run npm -g ls, and since some packages are distributed as self-contained installs via the use of bundledDependencies, they may come out of the package in a state that is inconsistent with npm#2's rules.
While this won't always work, most of the time the easiest way to fix these issues is simply to uninstall and reinstall the affected package. For packages that ship with bundledDependencies, if you really want to get everything cleaned up, you can cd into the node_modules folder containing the version of the package with the noisy prerelease dependency version and just run npm install problemDependency, and it will use the newest version of that dependency that matches the semver range for that particular package.
Re: your second question, semver range checking is done semantically, not lexically, so 1.0.31 should match with npm#2:
% semver -r '~1.0.2' 1.0.26 1.0.27-1 1.0.31
1.0.26
1.0.31
I suspect that the behavior you're seeing is due to a bundledDependency included in the package tarball.
All of this is documented, so I'm going to close this issue. I hope this clears things up for you!