Dedupe Packages
cressie176 opened this issue · comments
#701 highlights that we are not deduping packages using npm dedupe. We should run this before publishing a release, ideally automatically.
npm dedupe can modify package-lock.json, so running it from a GitHub action is not advised. Another option would be to run automatically using a pre-commit hook. Which would mean running it unnecessarily, and given it can take a few seconds, could be annoying.
Yet another option could be running npm find-dupes and failing CI if any are detected. I'm also open to other ideas.
How about doing it in a prepublish hook?
@cressie176 btw, shouldn't we remove package-lock altogether? it is irrelevant for libraries, as it will be ignored in end user applications anyway
How about doing it in a prepublish hook?
I was about to agree with you, then read your next comment...
shouldn't we remove package-lock altogether? it is irrelevant for libraries, as it will be ignored in end user applications anyway
I think you're right. I can't see any reason to include a package-lock.json with amqplib, which will entirely negates the point of deduping in the first place! I'll do a bit more reading then update.
I did some more reading around package-lock.json, mainly
- https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json
- https://dev.to/gajus/stop-using-package-lock-json-or-yarn-lock-3ddi
TL;DR
Committing amqplib's package-lock.json
- will not make any difference to projects that depend on amqplib.
- will provide a consistent set of dependencies for developers of amqplib & CI
- may hide issues experienced by developers depending on amqplib from the developers of amqplib, because of the different dependency trees
Potential Actions
Continue committing package-lock.json
+ amqplib development environments & CI are consistent
- Potentially makes it harder to track down issues experienced by amqplib users (I'm not aware of any issues so far)
Stop committing package-lock.json
+ May be easier to reproduce issues experienced by amqplib users (I'm not aware of any issues so far)
- amqplib development environments & CI will be inconsistent
Add a CI action to remove packgae-lock, install and run tests
If we add another GitHub action that removes package-lock.json before installing dependencies and running tests we will have
+ amqplib development environments & CI are consistent
+ May be easier to reproduce issues experienced by amqplib users (I'm not aware of any issues so far)
- Slightly slower build time
Option 3 seems like a good compromise
Doesn't option 3 still imply that CI and dev environment will be inconsistent? CI will still always install the latest dependencies, and developers will be using whatever is in package-lock
Doesn't option 3 still imply that CI and dev environment will be inconsistent? CI will still always install the latest dependencies, and developers will be using whatever is in package-lock
The idea was to keep the existing actions, but to add an additional one, which deletes package-lock. In this way we test
- The same dependencies that the developers use (via the existing action)
- The latest semver compatible dependencies (via the new action)
I don't think it will provide a great deal of extra assurance, because it still is unlikely to match the package-lock files that amqplib users have, but it might give early warning of a broken dependency.
I've thought about this some more, and unless we introduced a nightly build, there's very little point. The amqplib user base will be installing far more frequently than we push changes, so the latest semver compatible dependencies at build time will very quickly grow stale.
Another reason not to delete package-lock.json is because it's used by the github setup-node action for the cache key