Should the new template include an analysis_options.yaml?

[brianegan]

The current template does not include an analysis_options.yaml file, but most many projects include one. Should the template include an analysis_options.yaml file, and if so, what analysis options should be enabled?

• No
• Placeholder linking to further instruction
• Yes, using the Pedantic package
• Other options? Please provide your opinion :)

[rexthecoder]

This is something I was expecting, I asked a few people and I think Pedacntic was a nightmare to them for non-production works. Alessio recommends this article which I think is super useful to set up the analysis_options file( https://dash-overflow.net/articles/getting_started/).

Let me know what you think

[brianegan]

Thanks @Rexfordasamoah51!

I asked a few people and I think Pedacntic was a nightmare to them for non-production works.

This is very interesting! To help me understand the user needs a bit more, do you happen to remember any specific examples that were mentioned where the Pedantic package caused trouble? Is it all about the implicit casts mentioned in the article?

Thanks again :)

[rexthecoder]

They don't have a problem with it but the issue is that pedantic is very frustrating to them for small projects mainly non-production projects. Some said they use for only production works. But I will figure more about it on why (●'◡'●)

Alessio said > No pedantic is way too strict

[PiotrWpl]

I think that it's should be included, because I was surprised how many flutter devs are not aware of static code analysis tools in Flutter. And I'm also giving no to pedantic, https://pub.dev/packages/lint seems to be a better option. We started with pedantic in on of our big projects, but later we migrated to the lint package, and that was a good decision.

[orestesgaolin]

Yes, either pedantic or lint could be good options. Personally, I really like very_good_analysis, but this is related to a well known company, so I guess it wouldn't be a good choice for a template application.

I'd suggest adding simple manual rules as well to show newcomers that they can modify them as they wish.

[chimon2000]

Maybe just create a set of rules that the community can rally behind rather than use a set that may change?

[Arkangel12]

Well I do answer in another issue, haha but I definitely think this should be added, I prefer pedantic as a starting point that others but any of them should be good.

[RobertBrunhage]

My opinion is to just use Pedantic or lint. The main thing here is that something should be there. If this is aimed at novice to intermediate I do not advocate of having manual linting rules as most of novice developers don't even know about linting.

The only important part here is that it should be easy to change, which it is as the file is only including the linting rules. So changing the package or going with manual rules is a easy thing the developer can do independently.

But to add to this, a comment in the analysis file doesn't hurt, stating that there are other packages for linting or that it's possible to do it manually.

[rydmike]

Using a package for analysis_options.yaml is of course one way that works as an easy way out, without much further explanations. Certainly an option in order to keep things simple.

If it is included as a topic to explain a bit further, I would however instead of using a package recommend including and showing how to set up your own analysis_options.yaml. Include an example with some robust recommendations and also with good rationale and explanations of why at least those particular settings are recommended.

Some linting packages just include opinionated settings, with very little to offer on why the particular rules were chosen over some other, perhaps equally well considerable choices. Effective Dart and linting based on it, do a fairly decent job of explaining why some setting was used over another choice, plus why and when a setting can be helpful. Mostly it explains it well enough, but not always, it too falls a bit short sometimes.

Some rules are also more a matter personal/team/company choice, which is good to mention too. Packages and applications can also benefit from having different rules, which might be good to point out.

Personally I like the way of turning ALL rules ON (importing all rules) and then disabling conflicting rules (by turning OFF the one you do not want of the conflicting options) and then of course turning OFF the ones that it has been agreed/decided to not use in a project. To NOT use a particular linting rule, then becomes a considered choice and you can and should document why you made the choices in question.

I wrote a bit about it all here, just some personal preferences, the particular choices are not important. However, the Gist with my personal starting point analysis_options.yaml, (where I mostly just keep it handy for my own reference), contains reasonably extensive explanations, including my personal rationale and reminder (to myself), when I turned a lint rule OFF and why I decided to do so at the time. It also compares the made choices to the settings used in:

• Pedantic
• Effective Dart
• Lint
• Flutter repo.

Which in many cases of course conflict with each other too. Even if you don't always agree and do things that same way, checking and comparing what others do is always a good idea. For some lint rules there is not really any right or wrong, just different choices. Whereas some rules are very important if you want to promote and keep a certain coding style and perhaps strictness and robustness to it, which might not go well for people that like it more flexible and relaxed.

[asidt]

Like @rydmike says, and to try to answer the main question of this discussion: the template should definitely include an analysis_options.yaml file, and it shouldn't be pedantic (like I said 'No pedantic is way too strict'). It should instead be an example and show to every developer what they should do (based on Remi's and Mike's): start with all enabled options, and disable only a set of them. Now, which set to disable in the template is up to discussion as a separate topic, but I think it doesn't really matter, because everyone should anyhow go through all of them and choose their own set. It doesn't take too much time and it's very educative. I guess for the template purposes, few examples should suffice, like one about contradicting rules and maybe some very generic one, just to show practically how to disable them, and few comments on the reasoning behind them. The template shouldn't instead use any public package for that, because like MIke's pointed out some choices are very debatable and very opinionated, so IMHO better to let the devs the choice, instead of relying on the community.

[brianegan]

@rydmike thanks so much for the detailed write-up and sharing your own files -- I'll dig into it more. Great stuff.

@asidt That's interesting -- I find the pedantic package to be quite lenient, whereas the lint package is quite strict (which I personally appreciate, but might not be everyone's cup of tea). Which rules in pedantic have you found particularly annoying or overly strict?

[burhanrashid52]

Yes, using the Pedantic or lint package

[Ayobami-00]

Yes it should include an analysis_options.yaml file and I think the https://pub.dev/packages/lint package could work fine but if this template is targeted at novice flutter developers then understanding why some of the lint rules are so or why they are right might be quite hard to grasp at first. I find myself sometimes questioning why certain lint rules should be followed in some scenarios. So maybe a prior overview of linting may be required and maybe examples on how they can customize the lint rules

[Sunbreak]

https://github.com/flutter/flutter/pull/81417 fixed https://github.com/flutter/flutter/issues/78432 with a lot analysis_options.yaml into templates