Why do deprecation messages stick around on plugin code?


#1

I believe there should be a way to dismiss deprecation notices, at least for plugin code, mostly because the orange triangle is ugly and distracting and I can’t do anything to fix it :slight_smile:

I have 2 plugins that are triggering warnings. Issues have been reported against both of them, and one of them responded with effectively “Fixed, but deprecated code left for backwards compatibility”

Why should devs totally unrelated to the plugin have to deal with Atom complaining about it?

I’m aware that I can hide the notice using some CSS, disable deprecation cop, or the plugin itself, but I don’t feel that any of these are appropriate solutions.


#2

If it is fixed, have they released a new version where the deprecated code has been removed?


#3

No, they haven’t and apparently don’t plan to, which I understand since deprecated code doesn’t harm anything if there’s also forward compatible code in place (at least in this case, it’s complaining about CSS).

But that’s not really the point I’m trying to make. Regardless of what a plugin author does, whether they fix it or if they’re not responding at all, I don’t see why a dev that has nothing to do with the plugin should see a deprecation notice 24/7 until it’s fixed. I completely agree with raising the notice, but not with it being this persistent.


#4

I understand that you find it annoying and can sympathize with your point of view. On the other hand, I disagree that leaving the deprecated code in place doesn’t harm anything because at some point in the, hopefully, near future we’re going to remove the support for the deprecated code. When that happens, people’s editors and environments are going to break … so it is important for package authors to correct their packages before that happens. We feel that it is important for people to know that their environment is vulnerable to this.

If you have suggestions for how to:

  1. Ensure that people know they have packages installed that are vulnerable to breakage
  2. Be less annoying

I’d be happy to bring that feedback to the team.


#5

I’m not arguing that deprecated code isn’t harmful, just that in this case it isn’t (and in other specific cases).

When you click on the deprecation notice and drill down into the plugin there is an option to file an issue against the issue. I would propose that if an issue has already been filed (If I click it it jumps straight to an existing issue), and the user is aware of it, that the notice can safely be dismissed.

So having a [Dismiss] button next to [Check for Update][Disable Package] that shows up if an issue already exists would be a good solution in my opinion.


#6

What if that issue is never fixed?


#7

If it’s never fixed, Atom eventually updates, removes the deprecated call, and the plugin breaks. But that’s exactly what would happen anyway.

People either care enough about the issue to track it, or they’re going to ignore the deprecation warning forever until it breaks. Showing the notice forever serves no purpose for users in the 2nd case, it’s just intrusive.


#8

The author of the package should publish a version without the deprecated code.
They can then modify the package.json of the package with the following key…

"engines": {
  "atom": ">=1.13.0 <2.0.0"
},

That would then mean only users with an atom version between 1.13.0 and 2.0.0 would receive the updated package, leaving users with older atom versions with the old package version that includes the deprecated code…


#9

Again, my point is that this shouldn’t be dependent on the package author. What if the package is no longer supported? Or they’re just taking forever, or if they can’t be convinced to publish a new version, or …

The package author is ultimately the only person that should see this constantly on. Everyone else should be able to dismiss it if they want to as it’s distracting and has nothing to do with their work.

I should not be forced to see a warning that is 100% out of my control to dismiss.


#10

I’ve opened an Issue to track this on the deprecation-cop repository:

I’ll bring it to the developer team and see what they think. I can’t guarantee they’ll take this on but I’ll report back on the Issue with the decision.


#11

:slight_smile: Thanks!