Rename deno fetch subcommand to deno cache

[kitsonk]

The subcommand deno fetch is confusing, as it only implies partly what the subcommand actually does (and in some cases it doesn't fetch anything). What it does is parse all the dependencies of the root module, gather all the sources, and run them through the TypeScript compiler to populate the catch, but doesn't actually run the code.

We are likely to utilise the deno compile subcommand in the future to create a self contained binary, so the only other logically semantic term we could use is deno build deno cache.

This could also mean we could consider renaming the Deno.compile() API to Deno.build(), which is effectively the same functionality as deno fetch today. This would also mean that we would also have logical parity with deno bundle and Deno.bundle(). The one oddity is currently Deno.transpileOnly() but we have talked about --no-type-check flag (see: #4323 (comment)) and we would then want to move Deno.traspileOnly() to just an option of Deno.build() and Deno.bundle().

[hayd]

Or the other way around:

• deno fetch becomes deno compile
• "create a self contained binary" would be deno build

That said, I also wonder if "create a self contained binary" could be deno bundle with a flag...

[akshatagarwl]

@kitsonk Can I work on this?

[nayeemrmn]

Is there an applicable difference between compile and build, though? I think it should be something synonymous with deno prepare or deno ready.

Since it both downloads and compiles, we have to imagine flags that would enable disabling either (there are always tooling use cases) and deno build --no-compile wouldn't make sense.

[lucacasonato]

I think deno precache would make sense. That would also work with the no-compile option: deno precache --no-compile.

[kitsonk]

@humancalico I think we really need more input and consensus before it gets worked on.

[cknight]

I prefer deno compile as a replacement to fetch, with deno package or deno release reserved for creating a self contained binary. Compiling is a clear instruction and it shouldn't matter whether your sources are local or remote. If no-compile really is a potential future requirement then deno prepare is a better fit for me.

[kitsonk]

I don't think no-compile is a good name. It should represent what it would really do which is --no-type-check or --transpile-only.

[nayeemrmn]

@kitsonk Those sound different. --no-compile would be --fetch-only which does sound better. I just realised that what I meant by --no-compile would still require parsing deps... I guess fetching can't be extracted from the compilation.

[ry]

deno cache ?

[Soremwar]

@ry was about to say the same

deno build could have a target option
--target=binary
--target=module

[kitsonk]

Yeah, deno cache and deno cache --no-type-check or something like that certainly would work. The only "problem" would be that Deno.cache() feels a bit clunky, especially if you are supplying the sources. But maybe we would have this:

declare namespace Deno {
  cache(rootModule: string, options: CompileOptions): Promise<[Deno.Diagnostics, Record<string, string]>>;
  bundle(rootModule: string, options: BundleOptions): Promise<[Deno.Diagnostics, { content: string; map?: string; types?: string; }]>;
  bundle(sources: Record<string, string>, options: BundleOptions): Promise<[Deno.Diagnostics, { content: string; map?: string; types?: string; }]>;
  transpile(sources: Record<string, string>, options: TranspileOptions): Promise<[Deno.Diagnostics, Record<string, string>]>;
}

So deno cache and deno bundle would align a lot better to the current APIs and Deno.transpile() stands by itself, where you are feeding it the sources. It would type check by default, but accept noTypeCheck option, but it wouldn't be caching any of the inputs or outputs.

[nayeemrmn]

@humancalico I guess there's enough consensus now.

[kitsonk]

Yes, the --no-type-check flag and the changes to the runtime APIs are far more complicated. If interested, it is really just the rename at the moment.