deno: 🐛 `deno` v1.13 breaks shims using `--allow-plugin`

Opened #13325

If you have -A and that expands to include --allow-run what precisely could a future flag add that would be more powerful than --allow-run?

I get what it is trying to do, but I don’t think it’s reasonable. If a user says they want -A then we should trust they want -A. (Maybe we can print a warning to say “you installed with -A but we strongly recommend enumerating the permissions…”)

@MarkTiedemann , thanks for taking the time to look at this issue.

I do feel that I’m not correctly communicating the problem to you; I’ll try to restate it and improve my explanation…

I understand that --unstable is necessary to use the unstable APIs. I also understand that people who want to use them are knowingly buying into the unstable API with all that entails. I’m not complaining or concerned about the proper use of the unstable command line flags by devs using an unstable API.

But the important point here is that deno, during ordinary usage, is adding the unstable --allow-plugin (and --allow-ffi?) command line flag to all app shims installed using deno install -A ...; eg, here is what deno install -A ... creates…

% generated by deno install %
@deno "run" "--allow-read" "--allow-write" "--allow-net" "--allow-env" "--allow-run" "--allow-plugin" "--allow-hrtime" "https://deno.land/x/..." %*

and

#!/bin/sh
# generated by deno install
deno "run" "--allow-read" "--allow-write" "--allow-net" "--allow-env" "--allow-run" "--allow-plugin" "--allow-hrtime" "https://deno.land/x/..." "$@"

This is not specifically requested by the user installing the app and is for the most part opaque to casual users. And, then, this acts as a future trip mine which, without any warning, breaks all those shims when upgrading from v1.12 to v1.13, blocking use of all the apps installed using that installation directive.

error: Found argument '--allow-plugin' which wasn't expected, or isn't valid in this context
        Did you mean --allow-run?

USAGE:
    deno run <SCRIPT_ARG>... --allow-env=<allow-env> --allow-net=<allow-net> --allow-read=<allow-read> --allow-run=<allow-run> --allow-write=<allow-write>

For more information try --help

Again, I see this as a bug which needs to be addressed going forward to avoid tripping up ordinary users.

Likely, a good solution going forward is to never add unstable flags when installing using deno install -A .... Teach deno to add unstable command line flags only when explicitly requested, ie, for access to an unstable API, the dev must use deno install -A --unstable --allow-ffi ....

I believe requirement for --unstable is already in place. I think @dsherret’s PR should address the problem of forward compatibility.

Not stale.

This should be addressed at least as a policy statement going forward so that it doesn’t happen again…

Yes, @MarkTiedemann, we’re saying the same thing…

No, we’re not.

I’m suggesting that the bug is that the expansion of -A should not add (…) any unstable permission (eg, --allow-plugin or --allow-ffi, which it does) to the expansion of -A.

I’m saying that the bug is that -A should not be expanded.

There should not be a difference between deno run -A and deno install -A. I expect deno install -A to produce a shim that executes deno run -A.

@rivy Thanks for clarifying!

I was not aware that deno install -A ... produced a deno run shim including all --allow-* flags.

This seems like a design issue IMO, too.

I would have expected deno install -A ... to produce a deno run -A ... shim.

They should make the --allow-plugin flag an alias for the --allow-ffi.

They cannot be aliased because they are not the same thing: One is a native plugin API, the other is a FFI API. They are not compatible.

And if --allow-ffi goes away, it’ll break all over again.

Yes, it’s unstable, it may break. Deno’s stability is described in more detail in the manual: https://deno.land/manual@v1.13.2/runtime/stability

“You should be aware that many unstable APIs have not undergone a security review, are likely to have breaking API changes in the future, and are not ready for production.”

---

PS: If you are not sure about the stability of an unstable API, sometimes it helps to check the roadmap (https://github.com/denoland/deno/issues/11168). Usually, if an unstable API is mentioned, it’s either “stabilize” or “remove”. For example, “Remove native plugins API, introduce FFI API” has been the number 1 item on the roadmap for a while now. An example of an unstable API being stabilized is the new HTTP server which is mentioned as “Stabilize native HTTP server API”.