`Deno.shell` API

[felipecrs]

Hi,

The deno task shell is great because it allows to run several commands in a cross-platform way.

Could you also make it available under a JavaScript API?

Something like:

await Deno.shell("mkdir -p myfolder") // similar to deno task --eval 'mkdir -p myfolder'

It would be tremendously useful, avoiding the need of libraries like:

• https://www.npmjs.com/package/shx
• https://bun.sh/docs/runtime/shell

At least for the use cases covered by deno task.

What do you think?

[dsherret]

I'd recommend you check out https://github.com/dsherret/dax which works on all the major runtimes and doesn't have any runtime lock-in.

Libraries are a good thing for this case because it allows the API to evolve decoupled from the runtime. For example, in https://github.com/dsherret/dax I did a breaking change in the latest version to improve it. If that were built-in the breaking change could not occur as easily and would mean the behaviour a person gets is coupled to their runtime version.

Another point: I think Bun's shell made a few design mistakes and now they have that baked into their runtime as an API. Libraries are a good space to compete on these ideas rather than at the runtime level.

Additionally, this would further bloat Deno's API surface and dependencies. Every application would now have a dependency on this code instead of only the ones that import it as a library. For example, in the compiled executable for deno compile we don't even include the deno_task_shell dependency because it's not necessary for the runtime APIs, but with this change we'd start having to do that

[felipecrs]

Wow. dax is great. Thanks for letting me know about it.

But that's still one extra dependency I would need to add (I already depend on Deno, which already has this functionality and is just missing to expose it).

If that were built-in the breaking change could not occur as easily and would mean the behaviour a person gets is coupled to their runtime version.

Well, that's why you mark APIs as experimental and so on. And everything in Deno projects already depends on a certain minimum runtime version, that's not new.

Additionally, this would further bloat Deno's API surface and dependencies.

Maybe deno can inspect the use of Deno API during compile time and avoid shipping the unnecessary/unused bits? I suppose this would benefit not only this use case.

All that said, I would understand if you prefer not to.

[dsherret]

But that's still one extra dependency I would need to add (I already depend on Deno, which already has this functionality).

In my view, this is asking to have a runtime coupled dependency in all apps instead of just the ones that need it. Deno doesn't have all the functionality necessary for this and it would be a lot of code to add to get there.

Well, that's why you mark APIs as experimental and so on.

There are lots of stable node APIs that would never be created today because of advancements in API design and new langauge features/built-ins. Taking that to the next level and having such large APIs like a shell being built-in, would be a big mistake for the long run IMO. For example, dax (to my knowledge) was the first JS library to have a cross platform shell built-in. Had a shell-like library been built-in before that, I'm pretty sure it wouldn't have been cross platform, which IMO wouldn't have been ideal... and then we'd be stuck with non-ideal built-in bloat instead of just swapping out a dependency for the new improved thing. I think Bun is going to realize this in the future and do a breaking change to move to libraries (similar to how the .NET ecosystem realized this when moving away from the .NET Framework and broke up built-in functionality into packages that can be optionally dependened on at a specific decoupled version).

Maybe deno can inspect the use of Deno API during compile time and avoid shipping the unnecessary/unused bits? I suppose this would benefit not only this use case.

It would be very hard to do this. Most likely it would need to be opted-out by the user via a flag or something. Then there would need to be a way to only have the native code included in the binary sometimes, which would be technically challening.