I don't understand what this hyphen means in package.json.
I know the hyphen is usually used like "version1 - version2 Same as >=version1 <=version2".
https://docs.npmjs.com/files/package.json#dependencies
package.json
"#nuxtjs/pwa": "^3.0.0-0",
https://github.com/nuxt/create-nuxt-app/blob/master/template/_package.json
In this context, the hyphen indicates prerelease tags, such as 3.0.0-beta.0. Although it isn't documented anywhere that I've found, I believe the use of -0 as a prerelease tag says "accept any prerelease version". So this will accept any prerelease of 3.0.0.
There is a tool on the NPM website that allows you to see what versions are accepted by a semantic version range.
Related
As per
https://nodejs.org/dist/latest-v16.x/docs/api/all.html#all_packages_packagemanager
We can specify package manager from the list of supported package managers.
However, the VS code complains that the value is not correct.
I have also tried following values which also gives warnings
pnpm
pnpm#6
pnpm#6.0.0
pnpm#^6.32.4
#jonrsharpe, still the same warning without space
The packageManager field requires to match the following regex
(npm|pnpm|yarn)#\d+\.\d+\.\d+(-.+)?
And
"packageManager": "^pnpm#6.32.4"
seems to resolve the warning but, for example
"packageManager": "123!##pnpm#6.32.4"
also meet the regex, which implies that the former might not work as intended.
According to the PR on nodejs (deps: add corepack #39608)
How does Corepack work?
The sources are located inside nodejs/corepack. The gist is that Corepack installs "jumpers" next to the Node binary (just like what already happens for the npm and npx binaries) for the supported package managers (binaries are currently pnpm, pnpx, yarn, and yarnpkg, plus an extra one for corepack itself). They thus become exposed through the $PATH environment variable. Once called, these jumpers look into the local folder to find the top-most package.json, and read the packageManager field from them. Depending on the result:
If no packageManager field exists, the requested version is assumed to be the defaults ones in the Corepack configuration.
If a packageManager field exists, then it's used as the requested version.
And in Corepack configuration,
"pnpm": {
"default": "7.3.0",
...
}
The default version of pnpm is 7.3.0 as of now, which is used when packageManager field is omitted,
So it is best to set
"packageManager": "pnpm#6.32.4"
to ensure it working as intended.
Thanks to #jonrsharpe, the correct way to specify is
pnpm#6.32.4
The correct way to specify is:
"packageManager": "^yarn#1.22.19"
or
"packageManager": "^pnpm#6.32.4" ...
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"
}
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
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.
If I do npm install "grunt-contrib-uglify" --save-dev, the following line will be added to my dev-dependencies:
grunt-contrib-uglify: "^0.4.0",
I thought it was a best practice for a build script to refer to exact version of required tools, and manually upgrade tools when needed, in order to avoid regressions at an inappropriate timing in the build process.
So I was surprised that the added line is not
grunt-contrib-uglify: "~0.4.0",
Am I missing something here ? Should I always change the ^ to a ~ after using the --save-dev option ?
The ~ doesn't mean exact version either, both ~ and ^ are part of semver and indicate different levels of non-breaking changes i.e. it will bring down bug fixes and refactors but not breaking changes.
How much you trust this is up to you really. Do you trust the package owner to not introduce breaking changes when making bug fixes? Do you trust your testing to catch any problems? If not, then you would want to not have any symbol before the version to get the exact version. You can also shrinkwrap your dependencies.
EDIT: For more about the meaning of ~, ^, and other symbols in package.json, see https://github.com/isaacs/node-semver. For this specific case:
~1.2 := >=1.2.0-0 <1.3.0-0 "Any version starting with 1.2"
^1.2 := >=1.2.0-0 <2.0.0-0 "Any version compatible with 1.2"