chore!: remove npm shrinkwrap, use exact dependency versions

[Renegade334]

Resolves#1078.

We are currently locking consumers' dependency versions by using npm-shrinkwrap.json, which causes npm to lock the dependency tree to the npm-shrinkwrap.json versions when resolving.

We can achieve a similar effect by de-ranging the dependency versions. We weren't actually allowing npm to "choose" a dependency within these semver ranges anyway, because npm-shrinkwrap.json existed.

This approach wouldn't guarantee strict versioning of dependencies-of-dependencies for packages which specify version ranges for their own deps. The alternative would be bundleDependencies to basically ship a pre-packed node_modules, which would also give some version control over transitive dependencies, at the expense of quite a bulky package.

Either way, it'll be technically breaking because node-core-utils is now subject to external npm overrides, which shrinkwrap disallowed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.27%. Comparing base (78e1dbb) to head (9030665).

Additional details and impacted files

@@ Coverage Diff @@## main #1121 +/- ##
=======================================
Coverage 63.27% 63.27% =======================================
Files 50 50 Lines 8342 8342 =======================================
Hits 5278 5278 Misses 3064 3064 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aduh95]

We can achieve a similar effect by de-ranging the dependency versions.

That's not true, as you said after it only works for shallow deps. I'd rather just rename the file to package-lock.json

[Renegade334]

Any votes for bundleDependencies?

[aduh95]

Do we have some figures on how big of a bundle we're talking about?

[joyeecheung]

I'd rather just rename the file to package-lock.json

This wouldn't work for installing NCU globally, the idea is to pin the entire dependency tree when installing it globally (to prevent supply chain risks in transitive deps).

[Renegade334]

Do we have some figures on how big of a bundle we're talking about?

Looks like we would need to first upgrade c8 to eliminate the overrides for yargs, as this appears to cause npm pack to hang if bundleDependencies is enabled.

After doing so, npm is reporting a packed size of 120KiB for the conventional package, and 8MiB for the bundle, including 355 transitive dependencies. It won't make a difference for a first install, since all of those would need to be fetched anyway, but it will potentially make upgrades slightly slower (as the whole bundle will need to be fetched, even if dependencies aren't changing), and will impact upon npm dependency deduping, although this shouldn't matter too much for a global install.

[joyeecheung]

Since we just use node:test, maybe we can just use --experimental-test-coverage and stop using c8?

[Renegade334]

Since we just use node:test, maybe we can just use --experimental-test-coverage and stop using c8?

I've merged #1123 as a path of least resistance, we can always revisit this.

I'll put together a bundle-deps PR as an alternative, and we can take a verdict.