actions
No documented way to run without a lockfile
Description:
According to your docs there is no way to disable the lockfile check. They repeatedly say it is recommended to use a lockfile:
https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#working-with-lockfiles https://github.com/actions/setup-node?tab=readme-ov-file#checking-in-lockfiles
Unless I am missing it in some other docs I don't see it mentioned anywhere. But based on the code, it looks like you can avoid this check by disabling cache. I tested removing the cache key from my config and that did in fact work.
First, I would recommend not being so forceful in your wording on these docs. There are many cases for libraries where a lockfile is not the best approach. Many bugs have been found by users because the library author did not test removing their lockfile before publishing and used outdated transitives when testing. If you like you could link to the documentation written by the Node.js Package Maintenance Working Group which outlines a bit of the tradeoffs.
Short of that, I think an addition should be made to the advanced topics about turning off cache so that you can run without a lockfile.
Oh, and I forgot, there is also this from the OSSF: https://github.com/ossf/package-manager-best-practices/blob/main/published/npm.md#project-types
Maybe link out to these so folks can read documents from the experts in this space which will be updated as best practices change?
Thank you for creating the issue! We will consider it and come back with a response!
Hello @wesleytodd. The action has special input cache-dependency-path and it is usage described in the documentation and advanced section. You can specify different files to generate hash from it. In general we recommend to use package-lock.json because it contains all dependency tree and if versions of some dependencies are changed the new hash will be generated and resave cache. But with cache-dependency-path you can override it to different file.
The cache is optional input and it is not enabled by default.
The action has special input cache-dependency-path and it is usage described in the documentation and advanced section.
Yep! I read those. That is different than what I am mentioning here. I am recommending that the unnecessarily (see links provided above) strong recommendations around lock files be removed and that there be top level documentation around running without a lockfile.
I am happy to open PR's for these, but wanted to start the conversation as an issue before doing that work.
Lockfiles are pretty much required for applications. For libraries however, they tend to be anywhere on a spectrum from 'less useful' to 'obstructive'.
You really need a monorepo as well for lockfiles to make sense. If your application is made of a bunch of modules that have separate compilation units, you've created a massive maintenance problem by including lockfiles anywhere but at the deployment level.
