silverwind/updates

Flexible npm and poetry dependency update tool

updates

updates is a CLI tool which checks for npm and poetry dependency updates of the current project and optionally updates package.json/pyproject.toml. It is highly configurable and is typically able to complete in less than a second.

Usage

bun and node are officially supported. deno should work as well. For bun, replace npx with bunx and npm with bun.

# check for updates
npx updates

# update package.json and install new dependencies
npx updates -u && npm i

Options

See --help. Options that take multiple arguments can take them either via comma-separated value or by specifying the option multiple times.

If an option has a optional pkg argument but none is given, the option will be applied to all packages instead.

All pkg options support glob matching via picomatch or regex (on CLI, wrap the regex in slashes, e.g. '/^foo/').

Notes

The module uses global fetch under the hood. In Node.js HTTP proxies from environment are not supported, but it's still possible to enable updates to use them by installing the undici dependency into your project.

Config File

The config file is used to configure certain options of the module. CLI arguments have precedence over options in the config file, except for include and exclude options which are merged.

export default {
  exclude: [
    "semver",
    "@vitejs/*",
    /^react(-dom)?$/,
  ],
};

Config File Locations

The config file can be placed in these locations, relative to package.json:

• updates.config.js
• updates.config.mjs
• .config/updates.js
• .config/updates.mjs

Config File Options

• include Array[String|Regexp]: Array of dependencies to include
• exclude Array[String|Regexp]: Array of dependencies to exclude
• types Array[String]: Array of dependency types
• registry String: URL to npm registry

© silverwind, distributed under BSD licence

updates's Issues

Support `resolutions` field for yarn

Support GitHub API token

The current unauthenticated requests can lead to rate limiting. Should support a commonly used an environment variable to retrieve this token. Maybe GITHUB_API_TOKEN or whatever else is commonly used. For the paranoid, it could additionally also support a scoped name like UPDATES_GITHUB_API_TOKEN.

Not updating mutli version dependencies

$ cat foo.json
{
        "dependencies": {
                "eslint": "^1.0.0"
        },
        "peerDependencies": {
                "eslint": ">=1.1.0"
        }
}

$ updates -f foo.json -u
NAME    OLD      NEW      INFO
eslint  >=1.1.0  >=6.3.0  https://github.com/eslint/eslint
 ╭────────────────────────╮
 │  package.json updated  │
 ╰────────────────────────╯

$ cat foo.json
{
        "dependencies": {
                "eslint": "^1.0.0"
        },
        "peerDependencies": {
                "eslint": ">=6.3.0"
        }
}

this bug is found when I updating this sindresorhus/eslint-plugin-unicorn#351

Updating to dependency version that doesn't exist

turbocolor recently updated to 2.3.3 not 3.0.0. This also happened with the relative-date module but since that one is small enough I included it in my project wholesale.

Don't update all members in conditional chains

"eslint": ^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0

becomes

"eslint": ^7.0.0 || ^7.0.0 || ^7.0.0 || ^7.0.0 || ^7.0.0

Global installation

Looks like a nice project!

However, a lot of times my interest is in performing updates for projects which, while being useful projects, don't tend to keep their own project very up to date. And some of these projects' developers are resistant to even devDependencies additions. If this package can be installed globally, I'd suggest mentioning it on the README so more may be willing to try it out, and if it can't be installed with the -g flag, I'd love to see this feature.

Also, as it seems the tool supports color output, I'd highly suggest putting a screenshot, as, color, besides being a selling point for attractiveness, ought to be helpful semantically (assuming updates' color support is implemented, as I imagine it would be, to use colors differentially based on semver).

Option to delete modules and reinstall

After a dependency update, it's usually best to wipe node_modules and reinstall. I'm considering adding a command line switch to do just that for node_modules and whatever files yarn v2 uses, if present.

Support monorepos

Like https://github.com/facebook/create-react-app.

Rollup issue with [email protected]'s ESM exports

[email protected] adds ESM exports but this breaks our rollup build (color functions are undefined), need to investigate.

Support private git dependencies that use git+ssh

The module makes a HTTP call to github.

Would it be possible to support listening versions for a git dependency by spawning git as a child process

git ls-remote [email protected]:Raynos/error

Running git ls-remote will list all the tags and you can filter by v{semver} prefix.

Running git ls-remote as a child process will support PUBLIC and PRIVATE git dependencies, as well as support git dependencies that are not github.

--newest option

Fail updates with "Cannot read property 'latest' of undefined"

If package.json includes @reach/router registry, fail npx updates.

$ cat package.json
(snip)
  "dependencies": {
    "@reach/router": "^1.1.1"
  }
(snip)
$ npx updates
Cannot read property 'latest' of undefined

It seems to be because the @reach/router registry returns 404 and fetch response status is not checked it is 200.

I don't know why @reach/router registry returns 404.

(Verdaccio) TypeError: Cannot read property 'old' of undefined

Full error is:

TypeError: Cannot read property 'old' of undefined
    at Promise.all.then.dati (~/node_modules/updates/updates.js:216:38)
    at process.internalTickCallback (internal/process/next_tick.js:77:7)

I'm pretty sure this is an issue with Verdaccio, which is what I'm using for my self-hosted npm registry. I've run the update command in another project that doesn't use modules I'm self-hosting and updates has no problem.

Option to never downgrade while using `latest` tag

https://www.npmjs.com/package/@blueprintjs/core?activeTab=versions

Having 3.20.0 in package.json offers a "update" to 3.17.2 because that is currently the latest tag which is undesirable. Thinking of adding a option to prevent such "downgrades".

Support repository.directory

npm exposes this property on the registry so we can use it to link to subdirectories.

Support tarball dependencies

"uplot": "https://github.com/leeoniya/uPlot/tarball/a913c4e4f317502d217615c0d3c3c48e516ac490"

Write files via truncate+append

To better support WSL and Cygwin, write files via truncate+append, like microsoft/vscode@cc9d8fc.

Config files

For example, I'm forced to maintain some projects with a big number of legacy dependencies that can't be updated. It's not very convenient to maintain lists of such dependencies in CLI args. Adding a config file like .updatesrc could be very useful.

Support simple cases for `peerDependencies`

Support this in peerDependencies while retaining level of preciseness:

"webpack": ">=4" -> "webpack": ">=5"
"webpack": ">=4.1" -> "webpack": ">=5.2"
"webpack": ">=4.1.0" -> "webpack": ">=5.1.0"

Link GitHub repos to /releases

Most of my dependencies use the /releases page so I think we can link to it, saving a click when searching for the release notes.

Update readme with real update usage

Hey there,

I like your plugin a looot.
I just wonder if this is the right way to do, if i want to update my dependencies ?

updates --update && yarn install

And if it is, it may be a good idea to add it to the readme.

Bye !

a logic error in function `findVersion`

I was checking updates, logic here

updates/updates.js

Lines 418 to 436 in efcd4e0

	for (const version of versions) {
	const parsed = semver.parse(version);
	if (parsed.prerelease.length && (!usePre || opts.useRel)) continue;
	const diff = semver.diff(tempVersion, parsed.version);
	if (!diff || !semvers.includes(diff)) continue;
	if (opts.useGreatest) {
	if (semver.gte(semver.coerce(parsed.version).version, tempVersion)) {
	tempVersion = parsed.version;
	}
	} else {
	const date = (new Date(data.time[version])).getTime();
	if (date >= 0 && date > tempDate) {
	tempVersion = parsed.version;
	tempDate = date;
	}
	}
	}

can't handle this versions

const versions = [
  '1.0.0',
  '0.0.0'
]

I temporary fixed my local package use

versions = versions.filter(x => x !== '0.0.0')

package you can test with jpeg-buffer-orientation

Exclude updates by regex

Hello,

When I use the update into de monorepo, is necessary to exclude all monorepo packages, the update fail because the monorepo dependencies is not found in npmjs.... So, is possible to fix the error exclude all packages....

updates -u -m -e @name/pack1,@name/pack2,@name/pack3,...

I want a options to exclude monorepo packages to use a regex, for example:

updates -u -m -e @name/*

Best regards

Find a better `fetch` module

The dependency make-fetch-happen is not bundleable by rollup it seems, which I'd like to do for faster CLI startup. got seems like a suitable alternative but performed very poorly in my tests using the 1500 modules test (got takes 17s vs make-fetch-happen 4s).

So I'm looking for a fetch module that:

• Does proper caching of DNS requests
• Supports HTTP keepalive or its HTTP2 alternative
• Supports HTTP proxies (ideally directly from environment)
• Performs equally or better than make-fetch-happen
• Is bundleable via rollup

TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))

updates --update ./

TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))
    at checkUrlDep (/.../node_modules/updates/updates.js:541:35)
    at /.../node_modules/updates/updates.js:647:14
    at Array.map (<anonymous>)
    at main (/.../node_modules/updates/updates.js:644:66)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

package.json

{
  "dependencies": {
    "compression": "^1.7.4",
    "marked": "^0.7.0",
    "natural-orderby": "^2.0.3",
    "polka": "next",
    "sirv": "^0.4.2"
  },
  "devDependencies": {
    "@babel/core": "^7.7.4",
    "@babel/plugin-syntax-dynamic-import": "^7.7.4",
    "@babel/plugin-transform-runtime": "^7.7.4",
    "@babel/preset-env": "^7.7.4",
    "@babel/runtime": "^7.7.4",
    "@inc/eslint-config": "^2019.10.22",
    "@inc/stylelint-config": "^2019.12.1",
    "@inc/uchu": "^2019.12.1",
    "chronver": "^2019.10.2-7.1",
    "cypress": "^3.7.0",
    "eslint": "^6.7.2",
    "husky": "^3.1.0",
    "link-module-alias": "^1.2.0",
    "npm-run-all": "^4.1.5",
    "rollup": "^1.27.6",
    "rollup-plugin-babel": "^4.3.3",
    "rollup-plugin-commonjs": "^10.1.0",
    "rollup-plugin-node-resolve": "^5.2.0",
    "rollup-plugin-replace": "^2.2.0",
    "rollup-plugin-svelte": "^5.1.1",
    "rollup-plugin-terser": "^5.1.2",
    "sapper": "^0.27.9",
    "sass": "^1.23.7",
    "snazzy": "^8.0.0",
    "standardx": "^5.0.0",
    "stylelint": "^12.0.0",
    "stylelint-order": "^3.1.1",
    "svelte": "^3.16.0",
    "svelte-preprocess": "^3.2.6",
    "updates": "^9.1.0"
  }
}

I am not sure but I'm thinking that maybe some of my modules may be conflicting with how updates resolves versions. Four of the modules in my devDependencies are my own and are using ChronVer in favor of SemVer: @inc/eslint-config, @inc/stylelint-config, @inc/uchu, chronver. I also run my own registry (all but @inc/uchu exist on npm as well).

I'll keep investigating and report back if I find a workaround.

Auto-detect custom registry

Related to #19, examples:

.npmrc

registry=https://nexus.dev/repository/npm-proxy/
@mycompany:registry=https://myserver.dev/repository/npm-releases/

.yarnrc

registry "https://nexus.dev/repository/npm-proxy/"
"@mycompany:registry" "https://myserver.dev/repository/npm-releases/"

semver option should be scopable to packages

Support parsing yarn config files

I did a quick investigation and it seems to require one to pretty much re-implement yarn's internal config resolution, which I'd rather not like to do, so I'm hoping on yarnpkg/berry#264.

Probably depends on rexxars/registry-auth-token#27.

Golang support

I think it's not too far-fetched to have lightweight support for other languages like golang or python which I use a lot personally and having a single tool to update all dependencies is certainly valuable.

For go, If there is a go.mod file in the project directory, updates could check the go dependencies for updates via git over https protocol, possibly mimicking go get behaviour. Ideally it should be done without any additional dependencies being introduced and no further action shall be taken if no go.mod file is present.

For python, use a similar procedure with pyproject.toml.

Weird version issue

prismjs            ^1.10.0    ^9.0.0.0.0.1

published versions

[
  "0.0.1",
  "1.1.0",
  "1.10.0",
  "1.2.0",
  "1.3.0",
  "1.4.1",
  "1.5.0",
  "1.5.1",
  "1.6.0",
  "1.7.0",
  "1.8.0",
  "1.8.1",
  "1.8.3",
  "1.8.4",
  "1.9.0",
  "9000.0.1"
]

--greatest does not seem to work

I noticed when running updates against a project the newest release(date) gets used, but what i want is the newest version, so i switched to --greatest which somehow also wanted to downgrade a package.

How to reproduce:
Creating a new empty npm project and install electron (current version is 4.0.1 which is a month old) (newest patch 3.1.1 is a few days old) (https://www.npmjs.com/package/electron)

npx updates --greatest should not advise to downgrade the package.

just as a personal opinion. even without --greates updates should not advise to downgrade just because there is a new release for a older version

npx updates
npx: Installierte 107 in 6.28s
NAME        OLD       NEW       INFO
electron    ^4.0.1    ^3.1.1    https://github.com/electron/electron

npx updates --greatest
npx: Installierte 107 in 2.852s
NAME        OLD       NEW       INFO
electron    ^4.0.1    ^3.1.1    https://github.com/electron/electron

npx updates -g 
npx: Installierte 107 in 2.853s
NAME        OLD       NEW       INFO
electron    ^4.0.1    ^3.1.1    https://github.com/electron/electron

Fails with github package registry

When the package registry is https://npm.pkg.github.com, it's failing at line 246. It seems the github registry does not support the same API as npm.

Feature request: display release date

Registry response json has this info in time field on root.

1. for deps has updates, display the old/new version release date

This better be human friendly format.
Maybe additionally time diff of those two dates.

2. for deps without updates, display old version release date

---

Maybe like this

NAME	OLD	NEW	INFO
updates	1.0.0(29 days ago)	2.0.0(5 seconds ago)	https://github.com/silverwind/updates
updates	1.0.0(29 days ago)	2.0.0(yesterday, 28 days since old version)	https://github.com/silverwind/updates
updates	1.0.0(29 days ago)	-	https://github.com/silverwind/updates

Problem: maybe too much info to display

---

Reason behind this request

• for new updates, I want see when it's released, maybe I'll skip the one too young.
• for deps without updates, if it has been a really long time since last release, maybe I'll assume it's already dead.

Exit with error code

Hello,

I want to use the module for detecting package update in a release process.

The thing that I need if exit with an error code if a package need to be updated

The current behavior is:

❯ npx updates
npx: installed 103 in 3.324s
NAME     OLD       NEW
chalk    ~1.0.0    ~2.4.1

~/Projects/automatic-release master*
❯ echo $?
0

Just need something different to 0. Should be it the default behavior?

Other packages like https://github.com/tjunnone/npm-check-updates has a flag for do that:

-e, --error-level        set the error-level. 1: exits with error code 0 if no
                         errors occur. 2: exits with error code 0 if no

Please God Bless You Author

♥ thx

Add a registry mock for the tests

Tests are ran against live npm and need constant updating to pass. A registry mock would be nice to have instead.

what font is this ?

Shorthand

I would suggest clarifying in the README that the first part of && rm -rf node_modules && npm i is only necessary if you want to ensure your locally installed transitive dependencies and those in package-lock.json are also brought up to date.

While it's probably a generally good idea to do so, those on low speed connections or otherwise wishing to minimize time on updates, might not want to be forced to update those transitive dependencies when semver is still valid, unless perhaps there are vulnerabilities (e.g., as found by npm audit).

But if you are recommending it, you might want to add a flag which also handled this for the user. I use such updating frequently, and having to type all that extra text would be prohibitive to me. rimraf or rimraf-promise might be handy to implement if you were open to doing so. Just an idea.

Avoiding the error on `package.json` without dependencies

If package.json does not contain any dependencies,updates throws Error: No packages found. I think it could be good to add an option to avoid this behavior or remove it at all. Why? The monorepo case. Not all packages from monorepos contain dependencies and something like npx --workspaces updates will throw an error.

Output package homepage for fast changelog access

Often, I want to look at the changelog before updating a package. It would be cool if updates could output the homepage specified in the package's package.json to get to the changelog faster:

$ updates
NAME        OLD       NEW       HOMEPAGE
chalk       1.3.0     2.3.0     https://github.com/chalk/chalk#readme
got         ^7.0.1    ^8.0.1    https://github.com/sindresorhus/got#readme
minimist    ^1.0.0    ^1.2.0    https://github.com/substack/minimist

Breaking changes in 9.0.0

Hi @silverwind

Is there a list of breaking changes between 8.5.3 and 9.0.0?

I want to update but am worried about the breaking changes with the new major version

Support tag-based github dependencies

user/repo.git#v1.0.27

Allow limiting updates to latest minor/patch release

It would be nice if dependency updates could be limited to the latest minor or patch release. I'm looking for a way to auto-update dependencies without introducing possible breaking changes in semver major versions.

Unexpected behaviour with updates --patch

Hi, thanks for this great project.

I found something which to me looks like it could be a bug and I thought I should show you. When running updates --patch I received this entry:

styled-components  2.5.0-1  4.2.0  https://github.com/styled-components/styled-components

See what you think but, looking at the output of npm view styled-components versions, I would expect that no patch updates are available for [email protected] as the next highest version after 2.5.0-1 is 3.0.1.

EDIT: Just noticed this also happens with updates --minor

Thank you for your time.

prismjs case

Seems this popped up again:

$ updates -i prismjs
NAME       OLD       NEW         INFO
prismjs    1.15.0    9000.0.2    https://github.com/LeaVerou/prism

Cannot read property 'browse' of undefined

TypeError: Cannot read property 'browse' of undefined
    at getInfoUrl (~/node_modules/updates/updates.js:174:54)
    at Promise.all.then.dati (~/node_modules/updates/updates.js:192:30)
    at process._tickCallback (internal/process/next_tick.js:68:7)

I'm getting this in my projects when I run updates --update ./ My updates version is ^5.3.0.

Option to always ignore preleases

On [email protected] a update to a mistakingly published beta version is suggested because it is tagged as latest. It would make sense to add a option to never suggest updates to versions containing a prerelease tag if the old version did not include one.

Inverted meanings of --prerelease and --patch?

I'm using version 13.0.4.

From help message we got:

    -p, --prerelease [<pkg,...>]       Consider prerelease versions
    -P, --patch [<pkg,...>]            Consider only up to semver-patch

But I think these two options are inverted.

I have a package(name: my-lib) with versions:

0.2.0-alpha.1
0.2.0-alpha.2
0.2.0-alpha.3
0.2.0

And I have a project with dependency:

"my-lib": "^0.2.0-alpha.1"

Then I execute:

updates -i my-lib --prerelease

I think it should tell "my-lib" can update to "0.2.0-alpha.3", but it returns "0.2.0".

If I execute:

updates -i my-lib --patch

It returns "0.2.0-alpha.3".

So, are they inverted?

PS: My test env is company's intranet, so I cannot post actual screenshots. Sorry.

updates seems to ignore "strict-ssl=false" npm setting

Hi,
I've a configuration where I need to fetch npm packages from a private mirror in Nexus w/ self-signed CA certificates .
I've run "npm config set strict-ssl false" but still get the following error :

npx updates npx : 1 installé(s) en 5.671s FetchError: request to https://nexus.****.fr/repository/npm-npmjs-proxy/commander failed, reason: unable to get local issuer certificate at ClientRequest.<anonymous> (/home/****/.npm/_npx/15590/lib/node_modules/updates/updates.cjs:54:31315) at ClientRequest.emit (events.js:315:20) at TLSSocket.socketErrorListener (_http_client.js:469:9) at TLSSocket.emit (events.js:327:22) at emitErrorNT (internal/streams/destroy.js:106:8) at emitErrorCloseNT (internal/streams/destroy.js:74:3) at processTicksAndRejections (internal/process/task_queues.js:80:21)

Same error if I install updates globally w/ "npm -g i updates"

npm -v
6.14.12
node -v
v14.16.1
uname -a
Linux debian-dev 4.9.0-15-amd64 #1 SMP Debian 4.9.258-1 (2021-03-08) x86_64 GNU/Linux

Regards,
PS: thx for sharing this tool

request module should be a peerDependency

^ title