Lockfile should be written by default

[kitsonk]

Under certain conditions, the lockfile should be written and enforced by default. (raised as 2.0 scope by @bartlomieju)

[vwkd]

More previous discussion in #200

[dsherret]

We're planning on doing this by default in 1.28 if you have a deno.json file (so the lockfile would be automatically written beside that).

[jsejcksn]

The 1.27 release blog post links to this issue:

Note that in the 1.28 release we are planning to write a lockfile by default if you are using a deno.json file. Follow issue #11971 for updates.

Any improvement in increased integrity-checking by default seems great!

However, the information in the release notes combined with what's in this issue don't explain how this is planned to work — can someone from Deno core provide some clarity?

Here are my initial questions:

1. Is this for all Deno programs, or just the subset which use npm dependencies / Node compat mode?

2. Kitson said:

   Under certain conditions, the lockfile should be written and enforced by default.

   What I want to know:

   What are the "certain conditions" which are planned to enable this auto-writing behavior?

3. David said:

   We're planning on doing this by default in 1.28 if you have a deno.json file (so the lockfile would be automatically written beside that).

   and the Configuration File section in the manual includes this:

   The configuration file supports .json and .jsonc extensions. Since v1.18, Deno will automatically detect deno.json or deno.jsonc configuration file if it's in your current working directory (or parent directories). To manually tell Deno to use a specific configuration file pass --config path/to/file.json flag.

   ⚠️ Starting with Deno v1.22 you can disable automatic detection of the configuration file, by passing --no-config.

   What I want to know:

   3A. Does this mean that using the --no-config argument will also prevent auto-writing the lockfile?

   3B. Since the lockfile is planned to be written beside the deno config file, is there potential for any kind of conflict to arise from programs in subdirectories which don't have their own deno config (since each will walk the FS to find the closest parent deno config)?

[dsherret]

Subject to change...

Is this for all Deno programs, or just the subset which use npm dependencies / Node compat mode?

All.

What are the "certain conditions" which are planned to enable this auto-writing behavior?

When a deno.json file is resolved and no --lock <file> is specified. Probably there will be a cli flag like --no-lock to prevent it.

Does this mean that using the --no-config argument will also prevent auto-writing the lockfile?

Yes.

Since the lockfile is planned to be written beside the deno config file, is there potential for any kind of conflict to arise from programs in subdirectories which don't have their own deno config (since each will walk the FS to find the closest parent deno config)?

The lockfile will be additive so if multiple scripts resolve to the same deno.json then they will share the same lockfile.

[jsejcksn]

Thanks @dsherret.

Feedback/bikeshedding:

Probably there will be a cli flag like --no-lock to prevent it.

Since there's already --lock-write, another idea: --no-lock-write or --lock-write=false.

Perhaps this can (also) be configured using an environment variable (e.g. DENO_NO_DEFAULT_LOCKFILE=1).

[bartlomieju]

This is now done and will be released in v1.28.

@jsejcksn we went with --no-lock after all.

[jespertheend]

For the record, I'm already seeing a lockfile automatically being generated while using Deno 1.27.2. Not sure if this is intended.

[bartlomieju]

It is, if you use --unstable flag. With v1.28 it will be even without --unstable.

[jespertheend]

Ah that would explain it! I'm using --unstable yeah.

[randallb]

Thank you!! This is such a huge feature / usability win.