Have a way to enable _all_ lint rules _but_ a specific list

[rrousselGit]

Currently, all rules are disabled by default, and we have to enable each individual lint manually.

The problem is, on projects with a strict policy (that basically enables everything unless there's a specific reason not to), it becomes very difficult to read what is not enabled.

It would be incredibly more readable if we could do something like:

linter:
  default: true
  rules:
    some_lint: false

Which would enable everything but some_lint.

It would indeed "break" when new lints are added. But that is voluntary. They are only warning anyway and don't prevent shipping the app this way. But having the warnings ASAP, even if we don't fix them immediately, is very useful information.

[pq]

See also: https://github.com/dart-lang/linter/issues/1765.

Assuming we did that, it would look something like:

include: package:linter/rules/all.yaml

linter:
  some_lint: false

It would indeed "break" when new lints are added. But that is voluntary.

package:pedantic provides versioned rule lists (in addition to "latest") to address this issue. Something similar could be considered here (if that use case matters). IOW something like:

include: package:linter/rules/all_0.1.106.yaml

linter:
  some_lint: false

[rrousselGit]

Using include is not ideal. It doesn't work nicely with mono-repositories, where we have:

analysis_options.yaml
package/
  foo/
    pubspec.yaml
  bar/
    pubspec.yaml

[pq]

I'm not totally following. How is this different? Sorry if I'm being thick! 😬

[rrousselGit]

Including a "linter" package would be tightly coupled to the pubspec file and require a dev dependency

But analysis options can be shared between projects on a more global level, in which case they aren't associated with a pubspec file

[pq]

Ah, I see.

One thing to note is that you can use include: to reference a file as the front_end does:

https://github.com/dart-lang/sdk/blob/11a910323c8f06103bf52cee8b03be986f4759a3/pkg/front_end/analysis_options.yaml#L5

It would be interesting to consider extending it to allow URIs.

/cc @bwilkerson