cli: Add --no-remote, rename --no-fetch to --cached-only

[nayeemrmn]

Closes #3384.

[hayd]

This PR replaces/removes --no-fetch, to match #3384 change it should only add the flag.

As mentioned in the other issue I think --no-fetch is very useful. Another motivating example is to have deno fetch deps.ts then (at build time) deno fetch --no-fetch main.ts and (at runtime) deno run --no-fetch main.ts i.e. force all urls to be defined in deps.ts. This is useful for fast iterating in docker e.g. dockerfile with multi fetches.

[nayeemrmn]

@hayd Yeah, I just wanted to ask first if the added flag still sounded good. I guess there's some interest.

@ry Please review.

[ry]

@nayeemrmn There's something about this that strikes me as confusing or inelegant.

> deno help run
[...]
        --no-fetch                     Do not download remote modules
        --no-remote                    Do not resolve remote modules

> deno help fetch
[...]
        --no-remote                   Do not resolve remote modules

I acknowledge there is a use-case for both of these flags, but I can't help but wonder if they could be merged into a single concept.

I think it would be very helpful to users if a section in the manual was added (perhaps to https://deno.land/std/manual.md#linking-to-third-party-code ) which explained the difference and use cases for these flags in more detail...

[ry]

The documentation should describe these situations:

deno run --no-remote
deno run --no-fetch
deno run --no-remote --no-fetch
deno fetch --no-remote

It seems you would never need deno run --no-remote --no-fetch, because --no-remote is strictly stronger than --no-fetch. That suggests what perhaps we want a single flag that describes the behavior for remote modules...

[hayd]

What about a flag with a value? e.g. --no-remote=download or --no-remote=use.
(likely there is something semantically more pleasing...)

[nayeemrmn]

The purpose of --no-fetch is to fail at run if any dependencies are missing from the cache - a security feature for a CI edge case. --no-remote just bans remote modules. One makes assertions about the cache state and one constrains module resolution.

Correct me if I'm wrong, but the similarity between --no-fetch and --no-remote is an illusion caused by --no-fetch weirdly using module resolution errors and maybe its misleading name. They actually have nothing to do with each other and can co-exist just fine with some changes:

My suggestion is to rename --no-fetch to --cached-only, give it its own error
(--cached-only was specified but dependency x is not cached) and an appropriate help message
(Fail if any remote dependencies are not cached in advance). That makes the distinction a lot clearer.

Yes, --no-remote would render --cached-only meaningless but that would only be intuitive.

[nayeemrmn]

@ry I've implemented my above suggestion. Please review.

[ry]

@nayeemrmn --cached-only makes this much less confusing, thanks!

I think this could still use some more verbose documentation, but I'll leave that for future work.