Description
I'm opening this issue in this repository to discuss how to handle ecosystem affecting linter rule changes, such as this case when one of the effected lints is in one of the core sets. (As requested by Brian)
Currently, package_prefixed_library_names
which is in the core set isn't functional. The same goes for package_api_docs
which isn't in any of the core sets currently. This has been the case for the past few releases after dart-archive/linter@008a8a0.
Fixing/reimplementing these lints now is a bit dangerous as they are both quite heavily depended on, especially with package_prefixed_library_names
as part of the core set. It could result in a lot of new lints triggering on code with an SDK update.
So the question is if those lints starting to trigger on an SDK update are ok, or should these lints be removed from the core sets, deprecated, and slated for removal? If their functionality is still desired, we can always introduce new lints. Technically these both don't follow today's linter rule naming scheme anyway.
As an aside for these two rules specifically, but not relevant to the question of how to handle this in general:
- I think
package_prefixed_library_names
isn't super useful since users should generally shouldn't name libraries anymore. - While not the exact same behavior,
public_member_api_docs
covers many of the use cases ofpackage_api_docs
.
Metadata
Metadata
Assignees
Type
Projects
Status