Deno: [cli] deno fetch should accept glob pattern and multiple arguments

[keroxp]

Currently deno fetch only accept one argument of file but I think it's desirable to accept glob patterns and multiple file arguments. How do you think?

$ deno fetch **/*.ts

$ deno fetch a.ts b.ts



md5-c5f1a8c624d6d4f37b21c3e2ccbee990



$ deno fetch "**/*.ts" "**/*.tsx"

[lucacasonato]

Globs will not work with URLs as the web does not behave like a file system and can not list directory contents. This would only work for local files. Still useful for those but something we should be aware of.

The concept of "fetching" local files doesn't really make a lot of sense to me - you would only compile and not fetch the local files. Maybe deno fetch should be renamed to deno cache which makes more sense, it fetches the file if it is remote, compiles it and then caches it. For local files it would just compile before caching. That seems more logical to me.

[kitsonk]

Because globs cannot work for remote resources, I would be hesitant to introduce it personally because it would give a different experience for fetch from other commands and as noted would only work for local files. I am not sure of a good use case for it in the first place. Is there a particular use case you were thinking of @keroxp?

Those who are doing scripts to automate stuff would be better off expanding that using their shell versus expecting that from Deno's CLI. Just because we can doesn't mean we should! 😄

[keroxp]

I agree that deno fetch actually does more than just fetching but I don't understand what you are worrying about. Is there some specific problem about accepting glob and URLs together?

Why I proposed this features is that I want to prefetch and precompile all dependencies of project before deploying.

deno run may take too much long time to start and it's not desirable for deploying application to PaaS like Heroku. To avoid this behaviour, we need to list up files and run deno fetch manually. Especially ts files to be import dynamically are not referenced and compiled from root file and It takes long time to be served.

[kitsonk]

Why I proposed this features is that I want to prefetch and precompile all dependencies of project before deploying.

Why wouldn't you have a single main module then, which you would fetch?

Especially ts files to be import dynamically are not referenced and compiled from root file and It takes long time to be served.

That would be a valid use case. But then again, you assume that these would always be local?

[keroxp]

Why wouldn't you have a single main module then, which you would fetch?

Things are not specific to main executable. Think about automatically generated deno files that import other modules, or testing codes or example codes that are not referenced from any other files. It's difficult to know all implicit dependencies in the big project.

That would be a valid use case. But then again, you assume that these would always be local?

Yes. But even if it is not able to determine whether files to be imported dynamically are local or remote, pre-compiling local files are essential.

[ry]

Note that globs get expanded by the shell before they are ever passed to Deno. @keroxp is not asking for us to expand globs in our implementation, only that we accept multiple inputs for deno fetch - this is totally reasonable.

[bartlomieju]

This is a good first issue (should require changes only to cli/lib.rs)

[nayeemrmn]

Because globs cannot work for remote resources, I would be hesitant to introduce it personally because it would give a different experience for fetch from other commands and as noted would only work for local files.

@kitsonk This is how the test runner currently works: deno https://deno.land/std/testing/runner.ts --help. I guess in that case it's the URL support that's tacked-on but it's still a precedent.

deno fetch on a remote module vs the main module of a local project are completely separate usages. You're either doing one or the other. If there are capabilities that only apply to one case I don't think it would feel that off...

[kitsonk]

@keroxp is not asking for us to expand globs in our implementation, only that we accept multiple inputs for deno fetch - this is totally reasonable.

I was thinking about this, why wouldn't we want this to be tree for other commands as well, run, info, even bundle. The compiler already supports rootNames as an array. Any command that expects a module should actually expect _n_ modules, right?

[keroxp]

@ry unquoted globs get expanded by shell but quoted ("**/*.ts") not. Should we expand quoted patterns?

[bershanskiy]

I would like to work on this once the bike-shedding is over.

@keroxp said:

Should we expand quoted patterns?

If a person uses a particular shell, they probably get used to the way that particular shell handles quoted strings that look like regular expressions. As an experiment, I tried to use a couple different shells and see what they do. In some "**/*.ts" is a valid path for a file *.ts in folder **, in others it is an invalid syntax.
Obviously, I would never use these paths in an actual project, but if I ever ended up passing such a path to a program (e.g., in a script by mistake), I would expect it to treat it literally and not second-guess things.

[deepu105]

@bershanskiy are you working on this? else I can give it a shot

[bartlomieju]

FYI multiple files are already supported in deno fetch thanks to @yamalight (#3845). Glob support is still up for grabs, but I suggest to hold off until #3865 lands

[keroxp]

@bartlomieju I think it's been achieved now. I don't think it is essential to accept glob string as prettier does.
@yamalight Thank you for your contribution!

[bartlomieju]

Right, you can always expand globs in your shell as pass them as list to deno fetch