Warn when publishing breaking release with deprecated members #3959
Conversation
| d.dir('lib', [ | ||
| d.file( | ||
| 'test_pkg.dart', | ||
| "@Deprecated('Stop using this please') int i = 1;", |
There was a problem hiding this comment.
Why should this be a problem?
Yes, in theory a major version bump is a good opportunity to remove deprecated stuff.
But it's also entirely possible that my package contains multiple kinds of deprecated stuff, what if I want to keep sonme of the deprecated stuffs and remove other deprecated stuff.
In general, unless there is a pressing reason to remove something that's been deprecated, I would suggest not doing so.
You could do things like /// @nodoc in dartdoc documentation comments, to exclude the deprecated bits from documentation, so it doesn't pollute.
Would be nice if there was also a way to hide it from auto-completion.
Yes, in many cases it makes sense to cleanup when doing a major version bump, such that deprecated stuff disappears. But for large complex packages it's entirely possible that some deprecated stuff sticks around because it's low cost to keep, and removing it only causes friction.
There was a problem hiding this comment.
Yeah - good points...
Maybe we can lower this to a "hint"... I still think there is some value to extract here (the associated issue seems quite popular)...
There was a problem hiding this comment.
WDYT @jonasfj ? Should we make this a hint or close the issue as wontfix?
There was a problem hiding this comment.
I don't mind shipping it as a hint.
Are we sure this shouldn't just be a "lint" or diagnostic in the analyzer?
We run an analyzes run before publishing, right?
There was a problem hiding this comment.
Hmm - maybe that would work...
@pq what do you say? Would we like to be linted not to have deprecated members if the version is x.0.0 ?
Fixes: #2914
Open questions:
dart analyzevalidation?