3 ms·

One difficulty with NPM packaging is that it's traditionally quite hard to work out whether your dependency spec is correct or not. You can either keep bumping

One difficulty with NPM packaging is that it's traditionally quite hard to work out whether your dependency spec is correct or not. You can either keep bumping the version, or leave it be and hope no-one checks becuase it's hard to test. Shameless self-promotion: https://www.npmjs.com/package/downgrade-build https://www.npmjs.com/package/downgrade-build This duplicates your project in a temporary directory and locks all the direct dependencies to their lowest semver-compatible version. It's not infallible, but it helps. The only problem is that some projects rely on their direct dependencies bumping versions in order to force update transitive dependencies. Which is horrible, and also relatively easy to avoid needing to do by using a tool like Renovate.

lloydatkinson 3y ago
Pretty cool! Does it work with PNPM? I’ve mostly fully switched to that because NPM has for many years stood out as one of the worst package managers across ecosystems.
- andrewaylett 3y ago
  I'm afraid I've not tried it with PNPM, but it's unlikely to work without at least a small tweak as it executes an "npm run <script>" internally. You get to pick the script though.
philipwhiuk 3y ago
But the package.json isn't the important bit. The lock file is.
- andrewaylett 3y ago
  If you're shipping a library, it's the consumers' lock files that are important. You probably want your lockfile to be as up-to-date as it can reasonably be, for testing, but you also (at least in my opinion) should keep your dependency bounds as wide as is correct so you're not forcing dependency upgrades on your consumers. What Renovate recommend (and I concur) is specifying exact versions of development dependencies in your package.json, and broad version specifiers for peer and production dependencies. Then you use Renovate to test and bump the lock file versions, keeping them up-to-date. Downgrade build then helps you ensure that the lower bound on your peer and production dependencies isn't set too low.

lloydatkinson 3y ago

Pretty cool! Does it work with PNPM? I’ve mostly fully switched to that because NPM has for many years stood out as one of the worst package managers across ecosystems.

andrewaylett 3y ago
I'm afraid I've not tried it with PNPM, but it's unlikely to work without at least a small tweak as it executes an "npm run <script>" internally. You get to pick the script though.

philipwhiuk 3y ago

But the package.json isn't the important bit. The lock file is.

andrewaylett 3y ago
If you're shipping a library, it's the consumers' lock files that are important. You probably want your lockfile to be as up-to-date as it can reasonably be, for testing, but you also (at least in my opinion) should keep your dependency bounds as wide as is correct so you're not forcing dependency upgrades on your consumers. What Renovate recommend (and I concur) is specifying exact versions of development dependencies in your package.json, and broad version specifiers for peer and production dependencies. Then you use Renovate to test and bump the lock file versions, keeping them up-to-date. Downgrade build then helps you ensure that the lower bound on your peer and production dependencies isn't set too low.