Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No documented way to run without a lockfile #928

Open
wesleytodd opened this issue Dec 20, 2023 · 4 comments
Open

No documented way to run without a lockfile #928

wesleytodd opened this issue Dec 20, 2023 · 4 comments
Labels
feature request New feature or request to improve the current logic

Comments

@wesleytodd
Copy link

wesleytodd commented Dec 20, 2023

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.

@wesleytodd wesleytodd added bug Something isn't working needs triage labels Dec 20, 2023
@wesleytodd
Copy link
Author

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?

@nikolai-laevskii
Copy link
Contributor

Thank you for creating the issue! We will consider it and come back with a response!

@dmitry-shibanov
Copy link
Contributor

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.

@wesleytodd
Copy link
Author

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.

@aparnajyothi-y aparnajyothi-y added feature request New feature or request to improve the current logic and removed bug Something isn't working labels Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

5 participants