add unintended_html_in_doc_comment to core

[devoncarew]

• add unintended_html_in_doc_comment to core
• close unintended_html_in_doc_comment - add to recommended set #192

cc @kevmoo @lrhn @kallentu

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[natebosch]

We should be careful with this one because of the false positives. We might want to bump the min SDK constraint to an SDK version where we know this lint has no false positives.

[devoncarew]

We should be careful with this one because of the false positives. We might want to bump the min SDK constraint to an SDK version where we know this lint has no false positives.

Yes, good point. unintended_html_in_doc_comment exists in 3.5 but triggers on some false positives. The not-yet-released 3.6 sdk has the fixes. Thinking through this:

• if we keep the pubspec sdk min to 3.5, projects that rev to this new set of lints, but that run on a 3.5 sdk, will see some false positives for unintended_html_in_doc_comment
• if we rev the sdk min to 3.6, projects that update to the latest major version of this package will only be able to solve for their deps if they're running on a 3.6 sdk
• we could ship a 5.0.0 of this package w/o the unintended_html_in_doc_comment lint and with a 3.5 sdk dep, then ship a 5.1 version of this package w/ the lint and a bumped sdk dep of 3.6. people would then be able to rev to the latest major version of this package, but would see slightly more lints when running on 3.6 vs 3.5. This may not be an issue? It would be similar to the sdk introducing a new diagnostic

[natebosch]

• then be able to rev to the latest major version of this package, but would see slightly more lints when running on 3.6 vs 3.5. This may not be an issue? It would be similar to the sdk introducing a new diagnostic

Yeah I think that would probably be OK, the only risk is failing CI. I think the "false negative" of not having the lint at all is better than the false positives.