generate effective dart references from metadata

[pq]

Currently references to effective dart are managed manually in linter source, like so:

https://github.com/dart-lang/linter/blob/e52ab2a04676f910a73581afacd113b34da2c903/lib/src/rules/camel_case_types.dart#L15

And then done again in @tenhobi's list:

https://github.com/tenhobi/effective_dart/pull/21

And still again in the site docs:

https://github.com/dart-lang/site-www/commit/2b27eee58632a35fe0ca562ca45ba2aa1d288342

It would be great if some of this could be centralized.

To start, I propose generating the links in rule docs from an analysis options file (either fetched from https://github.com/tenhobi/effective_dart cached locally.

/fyi @kwalrath

[tenhobi]

It would be quite easy to show that line based on the presence in analysis_options.yaml since there is already fetching done for the effective_dart badge.

Do we want to point to a specific guide (style, documentation, usage, design)? That would be probably more complicated as it would require some context. Or even for example point to written rules where is a current lint rule used? Can we somehow "annotate" yaml using comments for example? Or is this too much complicated? For example:

linter:
  rules:
    # rule: url1
    # rule: url2
    # guide: style
    - lines_longer_than_80_chars

[pq]

Do we want to point to a specific guide (style, documentation, usage, design)?

If it's useful, absolutely.

Can we somehow "annotate" yaml using comments for example?

If we went that route we might have to use something other than package:yaml (since I'm guessing it disposes of comments).

Alternatively we could have another representation that contains the relevant data and then generates the various pieces from there. We could even, in that case, consider inling all of the relevant data in the rule sources themselves. analysis_options.1.2.0.yaml and so on could be generated from there in the same way as we produce badges. 🤔

[tenhobi]

Generating might be actually a great way (and easy), especially if for example we add analyzer error/warning/info to reflect the section of rules (https://github.com/tenhobi/effective_dart/issues/23) or any other tweaks in the future.

[tenhobi]

Hi @pq , I created a simple example of how it might be done - using a metadata file. See https://github.com/tenhobi/effective_dart/pull/25, what do you think?

[pq]

Sorry for slow response @tenhobi! 😬 I hope to look at this early next week.

[tenhobi]

Hi, just a friendly reminder. 😁😁 @pq

[pq]

Oh wow, sorry! I'll try and dig in over the next few days. It's more complicated than I thought!

[pq]

Sorry for the slow motion on this @tenhobi! It looks like this is kicking off a bigger (and much needed conversation). Talking this over with several folks it looks like this bears on the larger conversation around how we want to shepherd and maintain a preferred Dart style ruleset moving forward.

/fyi @mit-mit @devoncarew

[tenhobi]

That sounds cool. Let me know if I can do something. :-)

[pq]

That sounds cool. Let me know if I can do something

Will do. Thanks for nudging this and for all your energy in maintaining package:effective_dart!