Using semver as the standard, so I have this package version:
0.0.108
so in package.json for a Node.js project, I might have something like:
"foo":"^0.0.108"
my question is - using semver notation, how can I tell NPM not to install anything below 0.0.108? For example, 0.0.107 is unacceptable, but 0.0.109, or 0.0.111 is ok?
If you don't want anything in 0.1.x, then this should work
>=0.0.108 <0.1
If you are okay with any future versions, such as major releases, then you only need
>=0.0.108
Note the semver spec (Section 4) and the npm documentation on semver (Caret Ranges) both suggest there can be breaking changes for every release when the minor version number is still 0, so you may have to deal with those if you decide not to use ^0.0.108.
Related
My Vue devtools show this version hint:
I don't understand from where the version number 3.2.28 is coming though or to what exactly it refers to - my vue version is 3.2.25.
Can't see much more than what you provided in the image, but I think a reasonable guess is that you are using something like this:
"dependencies": {
"vue": "^3.2.25"
},
If that's the case, the install script will get the latest patch version, which would be 3.2.28 at the time of install, and 3.2.29 at the time of screenshot. This will also update the npm (or yarn) package which will make it re-install 3.2.28 even when 3.2.29
if you want to lock it, remove the ^ character, if you want to understand better why and how this is happening look into the Using semantic versioning to specify update types your package can accept documentation
My repo in github show the following alert :
Dependabot cannot update ssri to a non-vulnerable version. The latest possible version that can be installed is 6.0.1 because of the following conflicting dependencies:
terser-webpack-plugin#2.3.8 requires ssri#^7.0.0 via cacache#13.0.1
webpack#4.46.0 requires ssri#^6.0.1 via a transitive dependency on
cacache#12.0.4
The earliest fixed version is 8.0.1.
As far as I known, I should update the root package (which is terser-webpack-plugin) in package.json to a newer version, but how to determine the minimum version that can support the non-vulnerable version of the dependency (in this case ssri 8.0.1) since I don't want to update to a too high version and risk breaking things. I am thinking of manually checking through all the release version of terser-webpack-plugin, but it's very tedious and seem wrong to check like that. Any suggestions ?
To speed up the process and save installing each version and its associated dependency tree, we can use npm-remote-ls (https://stackoverflow.com/a/26005786/2815338)
Firstly get the list of available versions:
> npm view terser-webpack-plugin versions
[
'1.0.0', '1.0.1', '1.0.2', '1.1.0', '1.2.0',
...
Then run npm-remote-ls for each version after your current one and filter on the relevant dependency, e.g.
> npm-remote-ls terser-webpack-plugin#3.0.0 | grep ' ssri#'
??? ?????? ssri#8.0.1
??? ??? ??? ?????? ssri#6.0.2
In this case terser-webpack-plugin#5.0.0 is the first with only fixed versions of ssri (8.0.1), and 5.1.0 appears to not include ssri at all, presumably due to webpack no longer depending on cacache.
N.B. the question marks appear to be due to encoding of characters that npm-remote-ls uses to display a tree structure. You could also use Select-String in PowerShell, but this appears to show different (incorrect) characters instead.
I upgraded my router-flux version 0.27 to 0.30.
I am facing error of evaluating addListner I also submit it in the issue
4.0.0-beta.30 is broken as the last commit says
update dependencies, bump version - don't use, errors are possible!
4.0.0-beta.28 is broken too. Use 4.0.0-beta.27 instead.
In package.json, make sure you have exactly this:
"react-native-router-flux": "4.0.0-beta.27"
Don't include ^ otherwise your package manager will still install the .28 version (unless you have a yarn.lock at .27).
I get this error trying to use a github repository as a dependency using elm-install
Problem in dependency repo_name/package_name 1.0.0
The elm-package.json constraints of 'repo_name/package_name' are probably
letting too much stuff through.
What does this exactly mean?
(This answer courtesy of #ilias at Elm Slack channel)
It means that Elm couldn't compile the sources for that package in the context of your package.
Imagine for a minute I'm making a package my-fancy-package, and I have a dependency on a package foo/bar. So in my-fancy-package/elm-package.json, I could have a dependency like "foo/bar": "1.0.0 <= v < 2.0.0". Now, perhaps the most recent version of foo/bar while I'm developing my-fancy-package is 1.5.0. And in version 1.5.0, a new function was added that does exactly what I need in my-fancy-package, so I start using that function. The core issue is that there currently is no automated way to test that a package actually works with all the allowed versions of its dependencies. So now my-fancy-package says it depends on foo/bar at any version between 1.0.0 and 2.0.0, while in reality, it really needs to be at least 1.5.0 because I'm using a function from that package.
Now, imagine you're developing an application, and you're using foo/bar at version 1.2.3. According to the semver ranges of my-fancy-package, that means you should be able to use it, but if you were to actually try it, you'd receive this error: my-fancy-package is stating it is compatible with foo/bar#1.2.3 while it really needs 1.5.0.
The reason the error message doesn't simply say "it failed to compile" is because all the published packages are compiled before publishing. The most common reason for a package failing to compile in some context is that its dependencies aren't "accurate": they're letting too much stuff through.
In case of elm-install and packages from github, it's harder to say - it could actually be broken package.
Another common cause for this error is a rather silly one - conflicting definitions of infix operators. The associativity and precedence of infix ops can only be defined "globally", so if there are 2 packages that define the same infix operator, that could become a problem
We had been using version 0.11.0 of angular-bootstrap from npmjs. It appears that version is no longer available on npmjs. From the commands below does this mean that someone actually unpublished the older packages?
prompt:~$ npm view angular-bootstrap time
{ modified: '2015-01-12T06:48:54.881Z',
created: '2014-01-29T21:54:32.213Z',
'0.0.1': '2014-01-29T21:54:37.589Z',
'0.0.2': '2014-01-29T22:03:08.814Z',
'0.0.3': '2014-01-29T22:51:49.998Z',
'0.0.4': '2014-02-11T15:14:17.078Z',
'0.11.0': '2014-06-24T07:06:56.435Z',
'0.13.0-SNAPSHOT': '2014-12-02T13:05:43.151Z',
'0.12.0': '2015-01-12T06:46:41.986Z' }
prompt:~$ npm view angular-bootstrap versions
0.12.0
I agree, the package seems to have been unpublished. You can still access it from the github history, as follows:
$ npm install "angular-ui/bootstrap#0.11.0"
(note that you may not need quoting, but some shells will interpret the # as a comment-begin character.) You can also use this syntax in dependencies inside package.json
If you have a project in production that depends on this, you should probably make a fork of the angular-ui/bootstrap repository and point towards that.
(I had some difficulty making this work on Windows, but it looks like you're on a Unixy system, so you should be fine.)
Ticket discussing this and the future is at https://github.com/angular-ui/bootstrap/issues/1636