dart analyze --options does not exist (did with dartanalyzer)

[matanlurey]

How can I run dart analyze (or variants there-of) with a custom analysis_options.yaml file?

https://dart.dev/tools/dart-analyze does not mention anything, but the source code suggests --options.

I suspect this was lost in the dartanalyzer -> dart analyze migration.

[dart-github-bot]

Summary: The dart analyze --options command is missing, preventing users from specifying a custom analysis_options.yaml file. This functionality likely was lost during the dartanalyzer to dart analyze migration.

[bwilkerson]

It was intentionally removed as part of moving to using the analysis server (which was done so that we had less code to maintain). It doesn't make sense from an IDE perspective to be able to specify a different file at the point where you're starting up the server, so the capability wasn't available without extra effort, and there was no use case to argue for doing the work to preserve it.

If there's a valid use case for this functionality then we can put it on the list of features to add.

[matanlurey]

Fair.

This came up as a result of chatting with @pq a bit, where we were talking about "an analysis options set that isn't run on CI as a breaking, but we would like to be able to review periodically". As a concrete example, being able to add lint "deprecated_member_use" diagnostics that are normally ignored.

The workaround of course is just use the file system or manually patch files (I can't recommend that last one).

[pq]

I haven't thought about it much but another approach might be to add support that parallels the code option for dart fix:

Usage: dart fix [arguments]
-h, --help                      Print this usage information.
-n, --dry-run                   Preview the proposed changes but make no changes.
    --apply                     Apply the proposed changes.
    --code=<code1,code2,...>    Apply fixes for one (or more) diagnostic codes.

[matanlurey]

Ah that's interesting. I had seen at least one suggestion for something like:

dart fix --ignore-codes=<code1,code2,...>

You could imagine using that as an "auto fix" for existing deprecations.

[erecord]

My use case is that I want to use dart_code_metrics and (riverpod_lint/custom_lint).

However, there is a limitation of using one 'dart analyzer' plugin at a time. I can either use

analyzer:
  plugins:
    - dart_code_linter

or

analyzer:
  plugins:
    - custom_lint

So I have created:

• analysis_options.yaml which is the default one that my IDE will use
• analysis_options_custom_lint.yaml which I want to run manually in the command line since I can not use it alongside the default plugin

I would like there to be support for dart analyzer --options functionality in hopes that custom_lint can then support using a different analysis_options.yaml file.

This is so I can use a default plugin for my IDE (dart_code_linter) but then I can manually query the rules I'm violating under a different plugin (riverpod_lint/custom_lint) and I accept that I will be reading terminal output instead of the VSCode problems tab.

Thanks for any support into adding this functionality :)

[bwilkerson]

Thanks for the use case.

We are currently investigating to see whether we can drop the one plugin limitation. If we're successful, then we shouldn't need this added support in order to satisfy your use case. @srawlins

On the other hand, the Part files with imports proposal might make it necessary for us to have some similar configuration information in the analysis options file, which might in turn provide a similar use case for this functionality.