Find newer versions of package dependencies than what your package.json allows
Prerelease versions are now "upgraded" to versions with a different preid.
For example, if you have a dependency at 1.3.3-next.1
and the version fetched by ncu is 1.2.3-dev.2
, ncu will suggest an "upgrade" to 1.2.3-dev.2
. This is because prerelease versions with different preids are incomparable. Since they are incomparable, ncu now assumes the fetched version is desired.
Since this change affects only prereleases, there is no impact on default ncu
usage that fetches the latest
version. With --pre
or --target newest
or --target greatest
, this change could affect which version is suggested if versions with different preids are published. The change was made to support the new --target @[tag]
feature.
If you have a use case where this change is not what is desired, please report an issue. The intention is for zero disruption to current usage.
--target @next
. Thanks to IMalyugin.--stdin
option when reading package data from stdin.--retry <n>
option to automatically retried failed requests for package information. Defaults to 3 retries.Hopefully this relieves the frustrating situation of having npm-check-updates fail at the end of a long upgrade! You can control the number of retries with --retry <n>
, including setting it to 0
for no retries (the previous behavior).
peerDependencies
are now excluded by default. Peer dependencies should use the lowest possible version that works. The old behavior encouraged a bad practice of uprading peer dependencies. You can use --dep prod,dev,bundle,optional,peer
for the old behavior (#951).>
will be converted to >=
. The old behavior was causing upgrades to > [latest]
which was impossible (#957).npm-check-updates
as a module, vm
(versionmanager) is no longer exported. It was previously exposed for testing purposes, but was never part of the official API.Coming soon...
Early testers are greatly appreciated! In particular, let me know if you use any of the unofficial exports and can provide a case for their retention. Removing them will free up the internal API to do some architectural refactoring down the road.
Full details will be provided in the v12.0.0 release.
Wildcards and globs can now be used in filters without having to use regex:
ncu react-* # upgrade packages that start with "react-"
ncu \!commander # upgrade everything except "commander"
Since special characters are not allowed in package names, this change shouldn't break anything, but please let me know if a filter that was working before v11.2.0
is not now!
ee27448 Add filter support for wildcards and glob expressions. Fixes #219.
--packageFile
- Now interprets its argument as a glob pattern. It is possible that a previously supplied argument may be interepreted differently now (though I'm not aware of specific instances). Due to our conservative release policy we are releasing as a major version upgrade and allowing developers to assess for themselves.--deep
- Run recursively in current working directory. Alias of --packageFile '**/package.json'
.See: #785
https://github.com/raineorshine/npm-check-updates/compare/v10.3.1...v11.0.0
--filter
option and argument filters will now throw an error. Use one or the other. Previously the arguments would override the --filter
option, which made for a confusing result when accidentally not quoting the option in the shell. This change is only breaking for those who are relying on the incorrect behavior of argument filters overriding --filter
.See: #759
https://github.com/raineorshine/npm-check-updates/compare/v9.2.4...v10.0.0