Runtime agnostic CLI capabilities

[maarteNNNN]

Problem

When attempting to use JSR packages with CLI functionality across different JavaScript runtimes (Deno, Node.js, Bun), there are inconsistencies in how command-line arguments are passed and processed.

For example, with the @skedia/literal-sql package:

• In Deno, this works as expected:

  deno run --allow-read jsr:@skedia/literal-sql/cli --query "SELECT * FROM users" --where "active = true"

  Correct me if I'm wrong but I presume this is referring to the cli export in jsr.json.

• In Node.js and Bun, there isn't a way to use the library directly from the terminal, e.g.

  npx jsr @skedia/literal-sql/cli --query "SELECT * FROM users" --where "active = true"

Expected Behavior

CLI packages published on JSR should work consistently across JavaScript runtimes.

# Deno
deno run --allow-read jsr:@package/name/cli [arguments]

# Node.js
npx jsr @package/name/cli [arguments]

# Bun
bunx jsr @package/name/cli [arguments]

Suggested Solutions

Although currently not supported by default, is JSR willing to add CLI capabilities like NPM does?

1. Add an execution command to the JSR CLI tool, such as:

   # For Node.js
   npx jsr bin @package/name/cli [arguments]
   
   # For Bun
   bunx jsr bin @package/name/cli [arguments]

Impact

Improving cross-runtime CLI capabilities would significantly enhance the developer experience and increase adoption of JSR packages, especially for tools intended to be used from the command line.

[marvinhagemeister]

Although currently not supported by default, is JSR willing to add CLI capabilities like NPM does?

Yes.

[AugustinMauroy]

The feature will not work until jsr-io/jsr#284

[kuboon]

I hit this too, and ended up building a standalone tool for it:
jsrex — npx jsrex @scope/name, which does
on Node what deno run jsr:@scope/name does on Deno.

I would much rather this lived in jsr itself. A jsr x (or the bare
npx jsr @scope/name/cli shape proposed above) is where people will look for it,
and one tool beats two. If it lands here I will point jsrex users at it and wind
mine down.

In case it is useful, here is what the implementation actually needs. None of it
turned out to be hard:

• Resolve the version against https://jsr.io/@scope/name/meta.json, skipping
  yanked entries. An exact version needs no request at all.
• Install @jsr/scope__name from https://npm.jsr.io into a cache directory,
  with @jsr:registry scoped to that install so the user's own npm config is
  untouched. This is the part that makes it work at all: the npm-compat registry
  already serves the package transpiled with its dependencies resolved.
• Resolve the export subpath through the installed package's exports map
  (node/import/module/default conditions, plus ./* patterns), so
  @scope/name/cli addresses the same entrypoint Deno would.
• Spawn it with node <entry> ...args, forwarding argv, exit code and signals.

Two things that bit me, worth designing in from the start:

• The installer's stdout has to be kept off the program's stdout, or piping the
  program's output breaks.
• Deno permission flags (-A, --allow-net, ...) mean nothing on Node. Rejecting
  them outright is better than ignoring them silently, since ignoring implies a
  sandbox that is not there.

One caveat worth documenting whatever shape this takes: packages that touch Deno.*
fail at runtime. Packages on web standards and node: builtins are fine.

Happy to help with a PR if that would be welcome.