Skip to content

Deprecate iterable_contains_unrelated_type and list_remove_unrelated_type #58958

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
srawlins opened this issue Dec 8, 2022 · 11 comments · Fixed by dart-archive/linter#4360
Closed
Assignees
Labels
devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. linter-lint-proposal linter-set-core

Comments

@srawlins
Copy link
Member

srawlins commented Dec 8, 2022

in favor of collection_methods_unrelated_type

See my proposal to replace those two with the new rule in the lints package: dart-lang/core#787.

The best way to do this would be to ship a lints release with iterable_contains_unrelated_type and list_remove_unrelated_type replaced by collection_methods_unrelated_type, then deprecated them. This would result in less churn.

@pq
Copy link
Member

pq commented Dec 8, 2022

Great point re: less churn. We'll want to be thoughtful about how we time updates to package:lints. (See also: #58947 which proposes we deprecate a few recommended lints.)

@pq
Copy link
Member

pq commented Mar 16, 2023

@srawlins: I'm thinking this is a little close to the wire to pull off?

@pq pq added the type-question A question about expected behavior or functionality label Mar 16, 2023
@srawlins
Copy link
Member Author

Hmm close to what wire? I don't know what is involved with deprecating a lint rule, but it doesn't need to be... associated with any Dart SDK or language version, right? It's not breaking?

@srawlins
Copy link
Member Author

Although in the summary above I mention that the best way forward might be some work in the lints package first, before deprecating. No strong opinions here.

@pq
Copy link
Member

pq commented Mar 16, 2023

Hmm close to what wire?

Sorry, I wasn't clear at all! It was on the list to consider for 3.0. I guess I'd just like to push it to later.

@srawlins
Copy link
Member Author

Sounds good to me.

@srawlins
Copy link
Member Author

@devoncarew mentioned here it should be safe to deprecate first, then remove from package:lints. Mind if I ship that, @pq ?

@pq
Copy link
Member

pq commented May 15, 2023

You mean, deprecate these lints here now? Sure thing.

@srawlins
Copy link
Member Author

Sorry, I don't know what the difference is, but I'd like to remove the rules. Is there a reason to deprecate them before removing them?

@pq
Copy link
Member

pq commented May 15, 2023

The difference is that a removed lint will no longer work whereas a deprecated one will.

Is there a reason to deprecate them before removing them?

It's a nice way to give folks an opportunity to give feedback (and continue to give them lints before they've adopted the new recommendation).

Unless a lint is deeply broken or made obsolete (e.g., pre-null safety), I'd prefer a deprecation period.

We could add more details here I guess:

https://github.com/dart-lang/linter/blob/main/doc/lint-lifecycle.md#removed

@srawlins
Copy link
Member Author

OK

@devoncarew devoncarew added devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. labels Nov 19, 2024
@devoncarew devoncarew transferred this issue from dart-archive/linter Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devexp-linter Issues with the analyzer's support for the linter package legacy-area-analyzer Use area-devexp instead. linter-lint-proposal linter-set-core
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants