ci: run audit without package-lock.json file #326
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Auditing without package-lock.json to avoid false positives from dependencies where the version range is actually safe but the lock file is pinning to a vulnerable version.
sergiught
approved these changes
Oct 14, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
What problem is being solved?
Prevents failing npm audit failures (as seen on multiple open PRs) because
axiosis pinned in thepackage-lock.jsonfile to1.11.0. This dependency is pulled in through@openfga/[email protected]which declares a range of^1.8.3. This requires manual intervention to update the lockfile.How is it being solved?
Rather than running an audit against the dependencies pinned within this project, instead introduce the
--no-package-lockflag which will force npm to resolve the dependency tree and determine if there are any issues in the "live" dependencies rather than the (most likely) outdated lockfile references.Given that this project is a library and not an app, (personal opinion incoming) there is more value in working against what a consumer of the library would install when downloading the library to be aware of any broken functionality rather than using lockfiles as a means of security (we can do, but ideally we should move to limiting token access/usage etc.)
What changes are made to solve it?
Introduce the
--no-package-lockflag to npm audit.References
https://docs.npmjs.com/cli/v9/commands/npm-audit#package-lock
Review Checklist
main