About 'Discontinue dartanalyzer', could we have `--options`?

[eernstg]

Cf. https://github.com/dart-lang/sdk/issues/48457.

The command dart analyze replaces the old command dartanalyzer in a number of ways. However, dart analyze does not support the --options argument, which is used to enable lints and perform similar configurations that would otherwise be taken from analysis_options.yaml in a package.

The support for --options is very useful for the situation where a Dart program doesn't reside in a normal package directory structure, e.g., a script in a bin directory somewhere, or a bunch of different tests in a directory that aren't all using the same options.

It would be great if dart analyze could be enhanced such that it supports --options in the same way as dartanalyzer has always done it.

[bwilkerson]

I want to push back (gently) to understand the use cases better.

The analyzer doesn't assume that every file is in a package, instead it looks for a .dart_tool/package_config.json file in the parent directory chain to establish a mapping for package: URIs, and it looks for an analysis_options.yaml file in the parent directory chain to establish any overrides to the default options. Neither is required to be in a traditional package root (with a lib directory) nor are they required to be in the same directory; it simply takes the first such files it finds.

You mentioned two concrete use cases:

• a Dart program doesn't reside in a normal package directory structure, e.g., a script in a bin directory somewhere, or
• a bunch of different tests in a directory that aren't all using the same options.

The first can be handled by placing the analysis options file anywhere in the parent directory chain, such as in the bin directory.

The second could be handled by placing the files that share a set of options (even if that's a single file) in a subdirectory so that the analysis options file will only be applied to the tests in that subdirectory. (Which seems like it might be a useful organizing structure anyway.)

Would that satisfy your needs, or are there additional constraints that I'm not seeing?

[eernstg]

The first can be handled by placing the analysis options file anywhere in the parent directory chain

Yes, as long as there is no need for different programs/scripts to have different settings.

placing the files that share a set of options (even if that's a single file) in a subdirectory

Again, this relies on the assumption that the contents of the options file is static.

I understand that the following argument can be easily dismissed by saying "nobody else does that" ;-), but here's a concrete reason why I've been using --options many times, for years:

I've personally been using --options in order to perform experiments with tool behaviors and language semantics. I'd have a number of tiny libraries (5-50 lines of code, typically) in a directory, containing a bunch of experiments that were brought up (typically in github issues or at language team meetings). Some of the experiments would need to have special settings (for instance, enabling a specific lint). The support for --options made it possible to perform those experiments in a lightweight manner, without creating an entire package for every single program. Also, it was easy to have several different option files for the same source code, if needed.

However, I think this feature may be useful to others as well: Anyone who is using the language might want to perform experiments, not just to develop the language, but also to learn more about how a specific language feature or lint is actually working.

Finally, I think support for command line options including --options is helpful for Dart, in order to be able to claim that Dart supports server side programming, scripting (small Dart programs not in a package), and command line based usage in a more general sense (running the analyzer and compiler based on shell scripts and such).

I understand that the advice would generally be "just create a package, no matter how small your project is", but if we can preserve the support for --options then I for one will appreciate the convenience it offers.

[bwilkerson]

Thanks! That helps me better understand the use cases. To be clear, I'm not opposed to adding the support, just wanting to ensure that the support would justify the implementation and maintenance cost. Sounds like it brings a fair bit of value to the language team, and that seems like justification enough.

[eernstg]

Thanks for pushing on the clarification!

[jcollins-g]

The question I might have is; does this block removing --options from the original tool if it is otherwise not required? I'll leave @bwilkerson to make the call but if I don't hear otherwise, will preserve --options until a replacement is available as I don't think the cost of leaving it in for a bit longer is that high.

[bwilkerson]

Yes, I believe that the deprecated dartanalyze tool should continue to support the existing options for the time being.