What's the motivation behind the suggested changes?

I'm concerned about usability and consistency, and I'm not sure we're optimizing for that:

Why would we say -o must be followed by a space when most other command-line tools will except a space or no space? For consistency, all of our one-letter options that take an argument should all accept a space or no space.

What is the consistency behind boolean options? Consider --enable-checked-mode, --[no-]warnings, and --diagnostic-colors. These are all boolean flags, but there's no consistency in how you pick true, and how you pick false.

Finally, why would you not support /h and /? which are the common way to ask for usage on Windows?

Removed Priority-Unassigned label.
Added Priority-Medium label.

Why would we say -o must be followed by a space when most other command-line tools will except a space or no space? For consistency, all of our one-letter options that take an argument should all accept a space or no space.

Agreed completely. These should all be allowed and equivalent:
-ofoo
-o foo
--out foo
--out=foo

What is the consistency behind boolean options? Consider --enable-checked-mode, --[no-]warnings, and --diagnostic-colors. These are all boolean flags, but there's no consistency in how you pick true, and how you pick false.

I didn't notice this bit until after Dan sent it out, and I agree something more consistent would be good here. The args package follows POSIX/GNU guidelines and uses --foo to enable something and --no-foo to disable it. An omitted flag can default to on or off on a per-flag basis.

This makes sense to me. Let's do this. We'll need to support the same things for package root, as well.

This makes sense to me. Let's do this.

Is that to both parts of my comment? Would we change it to:

--checked-mode / --no-checked-mode

or do:

--enabled-checked-mode / --no-enable-checked-mode

?

I think --[no-]checked-mode is nicer (defaulting to --no-checked-mode)

I agree. Does "mode" add anything here? We could ditch that and have "--checked" and "--no-checked" (defaulting to the latter) and that gets us back to what currently works in the VM, right?

I fully agree with comment 7: Adding "mode" does not add anything useful as far as I can tell.

Agreed: --checked is the way to go. This is what dart2js has today. We added --enable-checked-mode to be compatible with the VM's option.

I agree with what Bob is saying in #­3, including making = optional in long options.

I'll update the table in all 3 tracking bugs to reflect these.

OLD NEW
-h|--help|/h|/? -h|--help
-p<path>|--package-root=<path> -p <path>|-p<path>|--package-root <path>--package-root=<path>
-o<path>/-o <path>/--out=<path> -o <path>|o<path>|--out <path>|--out=<path>
--disallow-unsafe-eval --csp[=no-unsafe-eval]
--suppress-warnings --[no-]warnings
--enable-disagnostic-colors --diagnostic-colors (no-op for now)
--enable-checked-mode/--checked/-c --checked/-c

                          
UNCHANGED FLAGS
--version
-v/--verbose
--analyze-all
--analyze-only
--analyze-signatures-only
--minify

One more question:

  --csp[=no-unsafe-eval]

Does this mean that both of these are valid:

  --csp
  --csp=no-unsafe-eval

If so, for what it's worth, that would confuse the args package and likely other argument parsers. An argument "grammar" tends to assume a given option either does take a value after it or doesn't. Here you have an option that can take a value, but only if it's a specific value. That's a bit hairy. Consider:

    dart --csp $1

This will mean different things based on what specific string $1 happens to expand to. (We don't require the "=" here because users expect to be able to omit it and have it mean the same thing.)

How about we just always make it take an argument? So:

  --csp=none
  --csp=no-unsafe-eval
  --csp none
  --csp no-unsafe-eval

Hopefully one last update.

OLD NEW
-h|--help|/h|/? -h|--help
-p<path>|--package-root=<path> -p <path>|-p<path>|--package-root <path>--package-root=<path>
-o<path>/-o <path>/--out=<path> -o <path>|o<path>|--out <path>|--out=<path>
--disallow-unsafe-eval --csp=(none|no-unsafe-eval) | --csp (none|no-unsafe-eval)
--suppress-warnings --[no-]warnings
--enable-disagnostic-colors --diagnostic-colors (no-op for now)
--enable-checked-mode/--checked/-c --checked/-c

                          
UNCHANGED FLAGS
--version
-v/--verbose
--analyze-all
--analyze-only
--analyze-signatures-only
--minify

What the --csp option controls is the value of "script-src". Valid values include: "none" (disable JavaScript), "self" (no eval and no inline script tags), and "unsafe-eval" (allow eval).

Clearly, "none" does not make sense for dart2js output.

The default in dart2js corresponds to "script-src: 'unsafe-eval'", and the output we generate to support Chrome extensions corresponds to "script-src: 'self'".

So I would say --csp accepts two arguments: "self" and "unsafe-eval", and "unsafe-eval" is the default:

--csp=self
--csp self
--csp=unsafe-eval
--csp unsafe-eval

So I would say --csp accepts two arguments: "self" and "unsafe-eval", and "unsafe-eval" is the default

SGTM.

Removed this from the M5 milestone.
Added this to the M6 milestone.

Removed this from the M6 milestone.
Added this to the M7 milestone.

Removed this from the M7 milestone.
Added this to the M8 milestone.