deno task feedback

[jespertheend]

I've been using deno task for a bit now and the blog post was asking for feedback. I'm running into some minor usability issues so I figured I'd post them here.

Introduction

First let me describe how I was running scripts before deno task was added. Basically all scripts have a shebang at the top of the file similar to what many of the scripts in the Deno project use:

deno/tools/format.js

Lines 1 to 2 in e55dee7

	#!/usr/bin/env -S deno run --unstable --allow-write --allow-read --allow-run
	// Copyright 2018-2022 the Deno authors. All rights reserved. MIT license.

I like this method because it keeps the required permissions close to the actual file, and running the script is extremely simple because all you have to do is run ./tools/format.js.

But the downside is... it doesn't work very well on Windows. Maybe I'm missing a simple solution for this, but as far as I can tell /usr/bin/env is not really a thing on Windows, and shebang support isn't great either. So Windows users are stuck with having to run scripts using deno run while trying to figure out what the required permissions are (or running with -A).
This wasn't a huge problem for me though. I'm mostly developing on macOS, so I was using shebangs for now, though I did want to have better cross platform support eventually.

deno task to the rescue

deno task makes it possible to easily run scripts cross platform, but the benefits from the shebang method are now gone:

• Permissions are no longer in the same file as the main entry point.
• deno task build -- --dev is more cumbersome to write than ./build.js --dev
• I reckon this issue is a bit more niche, but I feel the need to mention it anyway: Autocomplete for files no longer works when using deno task. I guess this depends on your shell as well, but before I used to do ./test.js path/to/file.test.js, where the last part of the command would get autocompleted by my shell. This is not the case with deno task test -- path/to/file.test.js. I suppose this is also caused by deno completions being installed.

Potential solutions

I'm currently using both methods, so every script has both a task configured as well as a shebang. That way Windows users can use deno task build and unix users can keep using ./build.js. But now there's two places where arguments need to be updated. If a developer on a unix system makes a change that requires different permissions they might only update the shebang, causing the deno task to break. And vice versa for developers using Windows.

Perhaps something like #12763 would make this easier. Though this won't take care of other arguments such as --unstable. And the location of the permissions would still be separate from the main entry point.

Though I think what I would prefer the most is if deno task were able to parse /usr/bin/env shebangs somehow. This way the file itself could use a #!/usr/bin/env shebang, and the configured task would only need to point to the file. Maybe a task could even look like

"tasks": {
    "build": "./build.js"
}

This already works on unix, on Windows it gives an error. This way, unix users could keep running files like ./build.js, and systems that don't support running files like this could use the tasks.
I'm not sure how far you'd want to go with making the tasks run cross platform. Since not only would this have to be able to handle running files via ./ syntax, it would also have to parse shebangs and implement /usr/bin/env somehow. Sounds like this is very much out of scope for Deno, but it would solve all issues mentioned above.

Conclusion

Anyway, those are my ramblings. Not sure how big of an issue this really is. I could certainly live with the current situation, I just feel like DX could be better here. Maybe someone knows a neat trick that allows you to run files on Windows in a similar manner. That would eliminate the need for tasks like these altogether.

[nhrones]

On Windows, I simply use vscode tasks.json.

"command": "deno",
                "args": [
                    "run",
                    "--watch",
                    "--unstable",
                    "--allow-env",
                    "--allow-read",
                    "--allow-net",  
                    "server.ts"
                ]

[jespertheend]

Ah yeah, that works in most cases. But I have a script for testing that I often have to provide with an argument for which file I wish to test: ./scripts/test.js path/to/file.test.js. In that case I have to use the command line.

[nayeemrmn]

• deno task build -- --dev is more cumbersome to write than ./build.js --dev

I recommend

"tasks": {
    "build": "deno run --unstable --allow-write --allow-read --allow-run ./build.js",
    "build-dev": "deno run --unstable --allow-write --allow-read --allow-run ./build.js --dev"
}

rather than pretty much ever relying on --.

Though I think what I would prefer the most is if deno task were able to parse /usr/bin/env shebangs somehow.

A lot of deno task is bridging Unix and Windows by re-implementing things for the latter. It wouldn't be out of place to supply a shebang parsing implementation for Windows, and a hook for /usr/bin/env as it has for some other commands already. @dsherret WDYT?

[jespertheend]

I recommend

"tasks": {
    "build": "deno run --unstable --allow-write --allow-read --allow-run ./build.js",
    "build-dev": "deno run --unstable --allow-write --allow-read --allow-run ./build.js --dev"
}

rather than pretty much ever relying on --.

Yeah this is what I'm using in most cases, but some scripts have so many arguments that it's infeasible to add all combinations. For instance my test.js script supports:

• --coverage to generate lcov coverage reports
• --html to also generate a html coverage report
• --no-headless to disable headless mode for puppeteer e2e tests
• --inspect and --inspect-brk to enable debugging the tests
• and on top of that it will pass along any unknown args over to deno test such as --filter

[dsherret]

Or even shorter:

"tasks": {
    "build": "deno run --unstable --allow-write --allow-read --allow-run ./build.js",
    "build-dev": "deno task build --dev"
}

Yeah, I opened denoland/deno_task_shell#23

[dsherret]

I thought about having deno task support running a task like ./my_script.js, but the downside is it encourages two ways of executing tasks for different sets of users. That said, if doing "./my_script.js" in a task already works on some platforms then perhaps we should just make it work on all. I opened denoland/deno_task_shell#23

Permissions are no longer in the same file as the main entry point.

Yeah, this is not as ideal, but I think there might be future improvements to the permission model that could solve this.

But the downside is... it doesn't work very well on Windows.

I've heard it also doesn't work on some versions of Ubuntu.

deno task build -- --dev is more cumbersome to write than ./build.js --dev

It should be possible to leave out the -- and just do deno task build --dev. This is a command you can then recommend to people regardless of their operating system.

Autocomplete for files no longer works

I opened #14039 to support shell completions for tasks in deno task.

[jespertheend]

It should be possible to leave out the --

Ah cool, I tried this with --inspect-brk which gave me an error, so I assumed it was impossible for all arguments.

[AnInternetTroll]

I've heard it also doesn't work on some versions of Ubuntu

The -S flag was added to gnu env in 2018, so anything before doesn't have it. Also OpenBSD doesn't support this flag afaik
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=668306ed86c8c79b0af0db8b9c882654ebb66db2

[martin-braun]

In singular cases (i.e. on main scripts) I do (assumming my script is main.ts and I wish to call it via ./cli on Unix or cli on Windows):

ln -s main.ts cli
echo "@ECHO OFF" > cli.bat
echo 'deno run --allow-env --allow-read --allow-net --ext=ts main.ts "%@"' >> cli.bat

Yes, it produces more files, but a simple bat file can enable you Windows support without any hassle. I do it only for main scripts for my project. I keep using the shebang method for Unix based environments.