feat(unstable/lock): autodiscovery of lockfile #16498
Conversation
| @@ -458,7 +458,9 @@ impl Flags { | |||
| Some(files.clone()) | |||
| } else if let Run(RunFlags { script }) = &self.subcommand { | |||
| if let Ok(module_specifier) = deno_core::resolve_url_or_path(script) { | |||
| if module_specifier.scheme() == "file" { | |||
| if module_specifier.scheme() == "file" | |||
| || module_specifier.scheme() == "npm" | |||
There was a problem hiding this comment.
This was fun - I tried this PR with Vite and couldn't get it to write to a lockfile. Turns out we never discover configuration file is the entrypoint is a npm package (eg. deno run -A --unstable npm:vite). This conditional now allows to discover configuration file in such case. Should I factor it out to a separate PR?
There was a problem hiding this comment.
Oh, interesting. I think this makes sense to do.
bartlomieju
changed the title
There was a problem hiding this comment.
Should we remove --lock-write flag?
What about a default value for --lock?
If I change the lock file and then run again with --lock=deno.json I get this error:
# deno run --lock=deno.lock --unstable -A main.ts
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.
Platform: macos aarch64
Version: 1.27.0
Args: ["deno", "run", "--lock=deno.lock", "--unstable", "-A", "main.ts"]
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', cli/npm/resolution.rs:311:43
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
No, it allows to overwrite the lockfile completely - eg. when you get into a situation where there's integrity mismatch, but want to update the lockfile, then specifying this flag will do the job. Error message suggests it:
What would be the default value?
Can you provide contents of |
yes
|
|
@ry all these problems have now been addressed. |
| Some(config_file) => { | ||
| if config_file.specifier.scheme() == "file" { | ||
| let mut path = config_file.specifier.to_file_path().unwrap(); | ||
| path.set_file_name("deno.lock"); |
There was a problem hiding this comment.
I was wondering if this should be deno-lock.json like package-lock.json, but I think this makes sense because then the formatter doesn't pick it up.
bartlomieju
changed the title
|
Is there a way to disable this behavior similar to how |
Not currently, no. Is there a reason why you don't want to use a lockfile? |
dsherret
changed the title
This commit adds autodiscovery of lockfile. This only happens if Deno discovers the configuration file (either "deno.json" or "deno.jsonc"). In such case Deno tries to load "deno.lock" file that sits next to the configuration file, or creates one for user if the lockfile doesn't exist yet. As a consequence, "--lock" and "--lock-write" flags had been updated. "--lock" no longer requires a value, if one is not provided, it defaults to "./deno.lock" resolved from the current working directory. "--lock-write" description was updated to say that it forces to overwrite a lockfile. Autodiscovery is currently not handled by the LSP.
This commit adds autodiscovery of lockfile.
This only happens if Deno discovers the configuration file (either
"deno.json" or "deno.jsonc"). In such case Deno tries to load "deno.lock"
file that sits next to the configuration file, or creates one for user if
the lockfile doesn't exist yet.
As a consequence, "--lock" and "--lock-write" flags had been updated.
"--lock" no longer requires a value, if one is not provided, it defaults
to "./deno.lock" resolved from the current working directory. "--lock-write"
description was updated to say that it forces to overwrite a lockfile.
Autodiscovery is currently not handled by the LSP.