📦 Package: Switch dependency versions to ^ ranges

[JoshuaKGoldberg]

Spinning out of #5090: @orgads noted that the package.json versions of dependencies are all pinned to specific versions like 4.1.1 rather than "caret" ^ ranges like ^4.1.1:

mocha/package.json

Lines 53 to 56 in 3345eff

	"dependencies": {
	"ansi-colors": "4.1.1",
	"browser-stdout": "1.3.1",
	"chokidar": "3.5.3",

Why is that?

I'm accustomed to ^ ranges to help consumers deduplicate packages. E.g. if a consumer's package requirements are chokidar@^3.5.2 and chokidar@^3.6.0, us specifying chokidar@^3.5.3 would mean they could all resolve to the same package version.

[voxpelli]

I'm a big 👍 to this. It was different in the pre-package-lock.json era, that's when it was good practice to try and lock down dependencies this way, now its better handled by the package-lock.json in our and other's projects.

Maybe implement this on a dependency by dependency basis when we update them? That way we will test that no breakage will occur

[JoshuaKGoldberg]

No comments for a while, and two 👍 votes. Accepting PRs!

Let's have a single PR for each dependency so we can test them separately - and revert separately if needed.

[the-sinner]

Hi, as far i understand, you want to add a caret symbol after each dependency below (except chokidar) in separate PRs ?

mocha/package.json

Lines 53 to 74 in 472a8be

	"dependencies": {
	"ansi-colors": "4.1.1",
	"browser-stdout": "1.3.1",
	"chokidar": "^3.5.3",
	"debug": "4.3.4",
	"diff": "5.0.0",
	"escape-string-regexp": "4.0.0",
	"find-up": "5.0.0",
	"glob": "8.1.0",
	"he": "1.2.0",
	"js-yaml": "4.1.0",
	"log-symbols": "4.1.0",
	"minimatch": "5.0.1",
	"ms": "2.1.3",
	"serialize-javascript": "6.0.0",
	"strip-json-comments": "3.1.1",
	"supports-color": "8.1.1",
	"workerpool": "6.2.1",
	"yargs": "16.2.0",
	"yargs-parser": "20.2.4",
	"yargs-unparser": "2.0.0"
	},

[the-sinner]

So, while reading about the caret symbol in package.json, i found this stack overflow comment

Posting here to hopefully catch people that don't quite think this through, but both ^ and ~ assumes you can trust minor and point releases from your dependencies. If you are publishing a library and want other people to trust you, DO NOT BLINDLY ACCEPT DOWNSTREAM DEPENDENCIES. A bad dot release from your dependency can cause a chain reaction upstream, and will have people knocking at YOUR door when things go pear shaped. This is another huge reason to use npm shrinkwrap on your production code. - tehfoo

Comment

So, it should be fine, right ?