[Question] What do you think of the ability for developers to add Custom Rules?

[hisaichi5518]

If I want to set my own lint rule for my library or my app, I need to create my own analyzer_plugin. I am using dart-code-metrics and I want to achieve that only with dart-code-metrics.

So I would like to ask what you think about adding a setting to dart-code-metrics for developers to set their own rules for their libraries and apps.

For example, you may want to set up a custom rule as shown below.
This has been inspired by the build_runner configuration.

analyzer:
  plugins:
    - dart_code_metrics

dart_code_metrics:
  import: 'rules/custom_rules.dart'
  rule_factories: ['myCustomRuleBuilder']
  ...

// rules/custom_rules.dart
import '...';

Rule myCustomRuleBuilder(_) => MyCustomeRule();

[incendial]

@hisaichi5518 to give a detailed response here I think we need more details about the expected API, so could you share your thoughts about that? Also, could you share a link to configuration you're talking about?

[hisaichi5518]

@incendial
Thanks for the reply!

The build_runner allows me to include code generation code in my packages. Similarly, I would like to include my lint rules in my package with dart-code-metrics.

The features I expect to see are as follows

• I can write my own lint rule for my package.
• I don't have to create tools/analyzer_plugin/bin/plugin.dart.
• I wrote my own lint rule and added the settings to analysis_options.yaml and the linter works.

The API for builder_runner is as follows.

• Defining Builders to apply to dependents
• example: macro_prototype/build.yaml at main - jakemac53/macro_prototype - GitHub

However, I am not familiar with analyzer_plugin, so I am not sure if the above API can be implemented.

[incendial]

@hisaichi5518 okay, I think that I understand your question better now, thanks!

Here is my point of view:
First of all, the idea of Dart Code Metrics is to use existing analyzer API for code analysis (metrics, rules, etc.) and what you are asking looks like another layer on top of Dart Code Metrics which will be used basically the same way Dart Code Metrics uses analyzer API. And it kinda bothers me in several ways:

1. We may end up providing analyzer features that we don't use, but that are useful for our external rules API.
2. The package is in an active development stage and we change things quite a lot. Providing external API for rules will block everything that is connected with them and we'll be forced to make major releases instead.
3. I'm not sure that it'll be a popular use-case for the package which leads to a lot of exposed API for a small group of users. And also require some time to be implemented correctly.
4. Although, I see that creating a separate package for rules only will require to use the analyzer as we do and also implement a similar logic that we have, I think that API like that should live in the analyzer itself instead of being provided by packages like Dart Code Metrics.

Summarizing all the points above: it'll increase the complexity a lot (and the most impact will be visible on a long distance), but the pros are questionable at least on a current stage of the package.

And if you have an example of a rule that you want to implement using this API, could you share it? Because I don't really understand the type of rules that can't be added to the linter or to this package and need this API instead.

[hisaichi5518]

@incendial
After reading your response, I feel that this feature should not be included in the current Dart Code Metrics. Thanks!

The rules I want to make are as follows.

• I want to prohibit the use of a specific Flutter Widget.
  • Flutter provides material design widgets like TextButton, but we have created our own widget, and we want to detect when we use TextButton.
• I want to prohibit methods that generate widgets (ex, _buildBody).
• Our code assumes DateTime(), so we want to prohibit DateTime.utc()
• I want to warn if there is any code in the state_notifier that has side effects.

I don't think it should be included in the Dart Code Metrics as it is just a rule I want for me and not a rule that others should use.

[incendial]

@hisaichi5518 thanks for sharing the list!

First one looks very generic and probably can be useful for a broader audience, so if you could create a proposal with a detailed description (ex. #332 or #364) we'll implement it. The proposal will help us tweak the rule behaviour and configuration.

Second one we already have, it's called avoid-returning-widgets.

As for third one, yeah, this one looks pretty local and unfortunately we can't add it, sorry.

And the last one is not that clear to me. If you could provide more details or formal criteria how side effects should be detected, then we can get a clear understanding on can it be useful for a broader audience or not.

[hisaichi5518]

Side effect refers to the process of calling the API, etc. It can be difficult to set up rules without relying on application code.
I'll close this issue! Thank you for your time.