Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cleanup: CLI global flags #3365

Closed
bartlomieju opened this issue Nov 17, 2019 · 6 comments
Closed

cleanup: CLI global flags #3365

bartlomieju opened this issue Nov 17, 2019 · 6 comments

Comments

@bartlomieju
Copy link
Member

bartlomieju commented Nov 17, 2019

We arrived yet again to the point where we need to cleanup our CLI flags.

Current output:

$ deno -h
deno
A secure JavaScript and TypeScript runtime

Docs: https://deno.land/manual.html
Modules: https://deno.land/x/
Bugs: https://github.com/denoland/deno/issues

To run the REPL:

  deno

To execute a sandboxed script:

  deno https://deno.land/std/examples/welcome.ts

To evaluate code from the command line:

  deno eval "console.log(30933 + 404)"

To get help on the another subcommands (run in this case):

  deno help run

USAGE:
    deno [OPTIONS] [SUBCOMMAND]

OPTIONS:
    -A, --allow-all                    Allow all permissions
        --allow-env                    Allow environment access
        --allow-hrtime                 Allow high resolution time measurement
        --allow-net=<allow-net>        Allow network access
        --allow-read=<allow-read>      Allow file system read access
        --allow-run                    Allow running subprocesses
        --allow-write=<allow-write>    Allow file system write access
    -c, --config <FILE>                Load tsconfig.json configuration file
        --current-thread               Use tokio::runtime::current_thread
    -h, --help                         Prints help information
        --importmap <FILE>             Load import map file
        --lock <FILE>                  Check the specified lock file
        --lock-write                   Write lock file. Use with --lock.
    -L, --log-level <log-level>        Set log level [possible values: debug, info]
        --no-fetch                     Do not download remote modules
    -r, --reload=<CACHE_BLACKLIST>     Reload source code cache (recompile TypeScript)
        --seed <NUMBER>                Seed Math.random()
        --v8-flags=<v8-flags>          Set V8 command line options
        --v8-options                   Print V8 command line options
    -v, --version                      Print the version

SUBCOMMANDS:
    [SCRIPT]       Script to run
    bundle         Bundle module and dependencies into single file
    completions    Generate shell completions
    eval           Eval script
    fetch          Fetch the dependencies
    fmt            Format files
    help           Prints this message or the help of the given subcommand(s)
    info           Show info about cache or info related to source file
    install        Install script as executable
    run            Run a program given a filename or url to the source code
    test           Run tests
    types          Print runtime TypeScript declarations
    version        Print the version
    xeval          Eval a script on text segments from stdin

ENVIRONMENT VARIABLES:
    DENO_DIR        Set deno's base directory
    NO_COLOR        Set to disable color
    HTTP_PROXY      Set proxy address for HTTP requests (module downloads, fetch)
    HTTPS_PROXY     Set proxy address for HTTPS requests (module downloads, fetch)

Most of the flags listen in OPTIONS section shouldn't be global and only available to run (deno run script.ts, deno script.ts) and fetch (deno fetch script.ts) subcommands.

IMHO I think following flags shouldn't be global:

  • --allow-* - for other subcommand we override flags anyway
  • --config
  • --current-thread - intricate runtime setting
  • --import-map
  • --lock
  • --lock-write
  • --no-fetch - only run subcommand
  • --v8-flags
  • --v8-options

Additionally some cleanup:

  • remove xeval subcommand (ref move xeval to std/examples/xeval.ts #3230)
  • work around [SCRIPT] subcommand that is visible - this is a hacky way to handle deno script.ts and I don't think it should be visible in help output, also shell completion is broken for it (ref zsh completion is broken #3310)
  • remove version - do we really need deno -v, deno --version and deno version? It might be cumbersome to configure that in Clap

Also, having deno script.ts and deno run script.ts would still mean that all flags specific to run subcommand should be printed with deno -h, but shouldn't be visible with eg. deno fmt -h

@bartlomieju bartlomieju changed the title cleanup: CLI flags cleanup: CLI global flags Nov 17, 2019
@nayeemrmn
Copy link
Collaborator

nayeemrmn commented Nov 17, 2019

  • --no-fetch - only run subcommand

Unfortunately deno fetch as well since it also compiles. Also I don't think deno test does/should override permissions, it should generally inherit deno run's options.

Fetches or compiles:

  • --config - fetch, run, test
  • --no-fetch - fetch, run, test
  • --import-map - fetch, run, test
  • --lock - fetch, run, test
  • --lock-write - fetch, run (NOT test, it wouldn't make sense)

Strictly runtime:

  • --allow-* - run, test
  • --current-thread - run, test
  • --v8-flags - run, test
  • --v8-options - run, test
  • --seed - run, test
  • remove version - do we really need deno -v, deno --version and deno version? It might be cumbersome to configure that in Clap

Also deno help?

@rsp
Copy link
Contributor

rsp commented Nov 18, 2019

@bartlomieju maybe it's not good time to implement right now but I'd like to remind my comment in issue #2081 with the idea of single-letter shortcuts for the permission parameters - which I tend to use multiple times per invocation, e.g.:

deno run --allow-read=config.json --allow-read=html \
         --allow-write=server.log --allow-net=:8000 server.ts

vs:

deno -R=config.json -R=html -W=server.log -N=:8000 server.ts

My idea was to reserve all uppercase single-letter parameters for permission shortcuts.

Maybe it's good time to revisit the idea.

Also, I was thinking about a separate permission for listening and for outgoing network connections (like there is a separate read and write for the file system) which was --allow-net for outgoing connections and --allow-listen for listening.

I remember that you also had an idea for --permission-map and I wonder if it's still considered.

(Some ideas like -e and --eval are outdated of course, since there is deno eval command.)

@bartlomieju
Copy link
Member Author

@bartlomieju maybe it's not good time to implement right now but I'd like to remind my comment in issue #2081 with the idea of single-letter shortcuts for the permission parameters - which I tend to use multiple times per invocation, e.g.:

deno run --allow-read=config.json --allow-read=html \
         --allow-write=server.log --allow-net=:8000 server.ts

vs:

deno -R=config.json -R=html -W=server.log -N=:8000 server.ts

My idea was to reserve all uppercase single-letter parameters for permission shortcuts.

Maybe it's good time to revisit the idea.

I don't have strong opinion on this one, @ry?

Also, I was thinking about a separate permission for listening and for outgoing network connections (like there is a separate read and write for the file system) which was --allow-net for outgoing connections and --allow-listen for listening.

Probably makes sense, but I'd open a new issue to discuss that, I meant this issue to only cleanup current situation without any new features.

I remember that you also had an idea for --permission-map and I wonder if it's still considered.

Yeah, ideally it would be some Web standard file that keeps it all (ref #3179)

@ry
Copy link
Member

ry commented Nov 19, 2019

I'd rather not introduce single letter abbreviations at this point for the permission arguments. Maybe we can later, but for now let's be explicit.

@bartlomieju
Copy link
Member Author

Done in #3389

@artisonian
Copy link

Was config dropped from the bundle subcommand on purpose? Not sure if I'm doing a niche thing, but I'm attempting to bundle TypeScript code using decorators (trying to get a snowpack experience for TypeScript without all of the tooling).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants