Make additive lock file optional

[sirikon]

Deno 1.27.1 introduced additive lock files:

• Release notes: https://github.com/denoland/deno/releases/tag/v1.27.1
• Pull Request: fix(lock): Additive lock file #16500

Before version 1.27.1, I could use the --cached-only functionality to ensure that, whenever I'm executing deno run, only the dependencies specified in the lock file are executed, giving me more control over when or how the lock file is updated, improving reproducibility.

I could limit lock file modifications to a single deno cache --lock-write and nothing else. Adding dependencies without "locking" them purposefully and then executing the project would result in a clear error.

I would love to have this functionality back. After version 1.27.1, I have no way to control this, and as a result:

• Reproducibility and security worsened, allowing the code on the repository to "work", but behave differently depending on when it was executed. Today I could commit an addition of a new dependency without locking it in, and the code would execute without issues, introducing the possibility of it behaving differently in the future by downloading a different version of the dependency.
• An automated build that checks that all the dependencies are present in the lock file becomes more complicated, needing to:
  • a) Check with git if lock file changed, and fail if so.
  • b) Have a separate DENO_DIR folder for each run, effectively disabling any possible caching.

It should be able to disable additive lock files. IMHO, it should actually be disabled by default or not even implemented in the toolchain, but the possibility to disable them by a flag would be an improvement.

PS: A change on how lock files are managed isn't something I would expect from a "patch" version. I can't find Deno's versioning specification, but many people would assume it's SEMVER because "it's three numbers separated by dots". Seeing Deno's versioning history, "minor" number bumps can mean breaking changes, but until today, didn't knew "patch" number bumps could mean breaking changes, too. Maybe some clarification over the versioning is worth the effort.