-
Notifications
You must be signed in to change notification settings - Fork 5.6k
fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE install interactions with lockfile #23918
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
fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE install interactions with lockfile #23918
Conversation
2b3c28a
to
39e093f
Compare
39e093f
to
9ee91a0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Overall looks good to me. Can you ensure we have a test that validates against a deno.lock
when installing and errors out if a dependency is broken and hash doesn't match?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I wonder if @dsherret has any comments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. LGTM!
Fixes #23571.
Previously, we required a
deno.json
to be present (or the--lock
flag) in order for us to resolve adeno.lock
file. This meant that if you were using deno in an npm-first project deno wouldn't use a lockfile.Additionally, while I was fixing that, I discovered there were a couple bugs keeping the future
install
command from using a lockfile.With this PR,
install
will actually resolve the lockfile (or create one if not present), and update it if it's not up-to-date. This also speeds updeno install
, as we can use the lockfile to skip work during npm resolution.