Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename deno fetch subcommand to deno cache #4600

Closed
kitsonk opened this issue Apr 3, 2020 · 15 comments
Closed

Rename deno fetch subcommand to deno cache #4600

kitsonk opened this issue Apr 3, 2020 · 15 comments

Comments

@kitsonk
Copy link
Contributor

kitsonk commented Apr 3, 2020

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
Copy link
Contributor

hayd commented Apr 3, 2020

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
Copy link
Contributor

@kitsonk Can I work on this?

@nayeemrmn
Copy link
Collaborator

nayeemrmn commented Apr 3, 2020

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
Copy link
Member

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

@kitsonk
Copy link
Contributor Author

kitsonk commented Apr 3, 2020

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

@cknight
Copy link
Contributor

cknight commented Apr 3, 2020

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
Copy link
Contributor Author

kitsonk commented Apr 3, 2020

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
Copy link
Collaborator

nayeemrmn commented Apr 3, 2020

@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
Copy link
Member

ry commented Apr 3, 2020

deno cache ?

@Soremwar
Copy link
Contributor

Soremwar commented Apr 3, 2020

@ry was about to say the same

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

@kitsonk
Copy link
Contributor Author

kitsonk commented Apr 3, 2020

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.

@kitsonk kitsonk changed the title Rename deno fetch subcommand to deno build Rename deno fetch subcommand to deno cache Apr 3, 2020
@nayeemrmn
Copy link
Collaborator

@humancalico I guess there's enough consensus now.

@kitsonk
Copy link
Contributor Author

kitsonk commented Apr 6, 2020

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.

@igotfr
Copy link

igotfr commented Apr 7, 2020

in Dart is:

$ pub cache add

or

$ pub cache repair

cache would make perfect sense

@kitsonk
Copy link
Contributor Author

kitsonk commented Apr 7, 2020

Closed in #4656

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants