Deno: discussion: Remove hack to make "deno $URL" alias to "deno run $URL"

[ry]

Problem: The parsing of the command-line arguments is not very good due to this alias. This is most obvious if you misspell a subcommand

> deno formatt
Cannot resolve module "file:///Users/rld/src/deno/formatt"

If we forced the user to type "deno run", then we would get a helpful help message instead of this.

It's a little more typing, but it's a lot more sane.

[nayeemrmn]

I feel like having the deno <module> alias is important next to python <module> and node <module>. Requiring the extra token kind of makes it feel less like a toy than them.

Flag error message problems similar to this will still exist in _lots_ of other places, the solution is one of those generally applicable Did you mean... plugins.

[cknight]

I agree with @nayeemrmn here. I love the simplicity of deno <module>. Straight and to the point.
Only a very small number of users will misspell subcommands and for many it should be reasonably obvious what the problem is. Do we want to force everyone to enter run for that small minority? Are there other misuse cases you were concerned about?

I'd almost flip this question. Is there a requirement for the run subcommand? I found it confusing at first, not understanding the relationship between deno run <module> and deno <module>. run feels unnecessary to me and effort could be spent improving parsing and error messages.

[SyrupThinker]

Alternatively one could force users to prefix the module with ./ to use the short version, \
as no sub command starts with . or /

[kitsonk]

We didn't have, then we forced "run", then we hated it and removed it again. Forcing it, this close to the API freeze... 😖

We have this thing called code which can perform analysis and the arguments. Building on what @SyrupThinker says... anything with a .js or .ts or a / or : is clearly intended to be a main module, and we could treat it as such. Anything else we could lazily match against the sub-commands and give a more useful error message. 😄

[Fenzland]

It will be new problems, such as shebang(currently, in most of Linux, /usr/bin/env not support -S).
Maybe we can just make it smarter.
Suggestion:

> ls
format format.js

> deno format
run subcommand format

> deno formatt
formatt is not a deno command, do you mean format

> deno ./format
run script ./format

> deno run format
run script ./format

> deno format.js
run script ./format.js
# or maybe
> deno format.js
invalid usage, please use 'deno ./format.js' or 'deno run format.js'

[crabmusket]

Does this "hack" also cause things like this?

$ deno -A test
Cannot resolve module "file:///src/test"

I got used to deno [flags] [file], so I naturally extended that to e.g. deno [flags] test, but actually that's not legal because the first command was actually implicitly deno run [flags] [file]. I've been tripped up several times by that, and more helpful error messages would have been great 😅

[szhu]

I actually kind of like having this removed? Requiring deno run makes it so that there is exactly one right way run a file, and that one right way works with every file name.

In particular, I remember only a few months ago getting similarly confused by Yarn's analogous shorthand. I added a package.json script called bin, but running yarn bin didn't do what I expected. Only after some digging did I realize that bin was a Yarn subcommand, and I had to use yarn run bin since the shorthand didn't work.

Just to clarify some of the possible sources of confusion:

• It could be confusing for users why they see people type deno do-something.ts on the command line but they see people write deno run $SCRIPT in shell scripts. (I've had this confusion before with Yarn.)
• Knowing which files can be run using the shorthand requires memorizing the full list of Deno subcommands. ("If I have a script called format, can you run deno format?")
• Having the shorthand sometimes be used makes it harder to see that Deno's command-line API has a consistent hierarchy.

Happy to hear how everyone weighs these cons of including the shorthand with the pros listed earlier in this discussion.