dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.25k stars 1.58k forks source link

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

Open matanlurey opened 4 months ago

matanlurey commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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:

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 commented 4 months ago

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.