`deno task` with no args should run first task

[nayeemrmn]

A useful feature of make is that it builds the first target when you don't specify any. deno task should do the same. This should typically be the start/serve task. Currently deno task lists available tasks, I think we should move that to deno task -l.

[kitsonk]

I wouldn't be supportive of this... it is ambiguous and surprising. The current behaviour of listing the tasks make more sense to me.

[dsherret]

Yeah, that seems like surprising behaviour to me given how npm run works. I often use deno task on its own to find out what the tasks are.

[nayeemrmn]

But I think people will get used to it very quickly. There is prior art in make and it feels very normal there. Between the reduced keystrokes and having a command that works across any application, it seems like a massive improvement in DX.

[dsherret]

I don't think it's that much of an improvement in DX because very often repos have different commands for development, production, or something else.... so I'd still need to go into a repo and find out what convention they're using for "first command" before running it or ensure they're following whatever the recommended convention is. So I think going into a repo and finding out what those commands are by typing deno task is nice to have and removing that would be a step backwards. #14039 would be a nice improvement and reduce keystrokes.

With make it feels normal because the command is called make... deno task doesn't have that same feel to me personally. I think in the JS ecosystem npm run's behaviour has greater precedence for prior art.

[nayeemrmn]

I don't think it's that much of an improvement in DX because very often repos have different commands for development, production, or something else.... so I'd still need to go into a repo and find out what convention they're using for "first command" before running it or ensure they're following whatever the recommended convention is.

But you're probably going to repeatedly run the command for a repo you're familiar with more often than you'd switch between repos. Not needing to specify on every invocation an arbitrary keyword specific to each project alleviates a lot of cognitive tax, even if you still have to verify once per project that the main task is what it should be (i.e. start dev server).

#14039 would be a nice improvement and reduce keystrokes.

Well with shell completions implemented, you can regardless see a list of tasks by typing deno task [tab][tab] which largely supersedes the current behaviour. Or to pretty print with descriptions, I'm only proposing to move that to deno task -l not remove it. And for example I'm in the habit of instead using code deno.json so I can also glance over what commands are actually run. The point being that, listing the available tasks has too many alternative syntaxes to take the valuable spot it currently does, whereas a shortcut to "run the main task" has very few priorly-seen alternatives if any.

[zicklag]

I'm not so sure about having a default task that runs just by typing deno task. If we really want a default task kind of operation, then maybe do it similar to NPM where you have npm run [task] or npm start, where npm start just automatically runs the start task instead.

Or maybe we allow the tasks to be called similar to cargo plugins, where you just say cargo edit like it's a cargo subcommand, even though it's a plugin.

So if you had a make task you could run deno make and if you had a run task, you would have to run deno task run because it conflicts with the built-in deno run command.

[gutenfries]

I'm not so sure about having a default task that runs just by typing deno task. If we really want a default task kind of operation, then maybe do it similar to NPM where you have npm run [task] or npm start, where npm start just automatically runs the start task instead.

[...] if you had a make task you could run deno make and if you had a run task, you would have to run deno task run because it conflicts with the built-in deno run command.

In yarn, the behavior of (yarn | npm) run is slightly different, and I believe it would increase productivity. https://classic.yarnpkg.com/lang/en/docs/cli/run/#toc-yarn-run-script

When running yarn run {script} the behavior is almost identical to that of npm. However, similar to what @zicklag proposed, yarn start will run a task named start, any arguments passed going straight to the task without the need for -- {flags} is a task is not found with the name of the phrase you pass after yarn {your-phrase-goeth-hereth} yarn returns the same error {TODO}

If you have tasks with the following names:

The different behaviors or yarn are as so:

• If you run yarn run, yarn asks you what script to run, ignoring the script named run. if you wanted the run script to be executed, you would need to specify yarn run run as this conflicts with an internal yarn command.

• If you run yarn start, it runs the start script, quintessentially the same as running yarn run start. This is the expected behavior of a script whose name does not conflict with an internal yarn command.

I think that we could do something similar for deno task, receiving the benefits of fewer keystrokes while maintaining consistency across node-based toolings. This will be the most expected behavior of deno task for node users and certainly is less risk-involved than having deno run the first task in the JSON.

[gutenfries]

I opened a PR (#16194) with appropriate changes, to modify the behavior of deno task

[dsherret]

Closing for reasons stated above.