Deprecated Atom APIs will be removed on June 1st


#1

See the blog post here:


#2

#3

Is there a way to find deprecated code other than waiting for the code to hit the deprecation during execution? It will be very hard for me to exercise all my packages enough to hit every deprecation. Even if I had tests (grin) they wouldn’t give 100% coverage.

I would think having a list of the names of all the deprecated calls and doing a text-search would do the trick. If this doesn’t exist I’ll do a package.

BTW, is there a guarantee that there won’t be any more deprecations this month? Every deprecation must be announced some time before it throws errors. That’s what the word deprecate means.


#4

All of the deprecations have been unified at the bottom of the code files they appear in under an if includeDeprecatedApis clause. You could search through the source and take a look at each one to see if they apply to your packages.

There is also now the --one command-line flag so you can run Atom in a “post-removal” mode, so that instead of getting a notification in Deprecation Cop, the code just throws.

I haven’t heard of one, no.


#5

I would still have to be lucky enough to hit that code.

I would have to make a list of them and refer to that list as I read through the thousands of lines in my packages. That would be quite a pain (n-squared problem). I think it would be easier to make a list and then search the packages for each term in the list.

I’m sure A bash script could be done for this but doing a package would be easier for me. And it might be useful to others. It would certainly be more dependable than waiting for errors.

The user could just enter a list of package-names and then the package could retrieve the code. I could even run it on all packages!!!

Edit: It could send an email to every author with a list of offenses with the file-name/line-number and maybe even some code around the offense. I don’t think this would be spam because it would be a one-time mailing and the could just delete it. The whole process would improve the quality of atom overall.

A few days before June 1 I could post a list of offending packages here and hopefully shame the authors into fixing them.


#6

But it significantly lessens the chance that you’d miss the notification :grinning:


#7

I’d really rather you didn’t. Public shaming is an ineffective tool at best and a detrimental one at worst.

Deprecation Cop has long included a feature where end-users can submit issues to the package’s repository. For example, here is an Issue from one of my packages:

(which I forgot to close last night when I fixed it … :laughing:) I think submitting bugs on a package’s repo is a much more effective tool.


#8

Yes, that is much better than shaming. But I still think one list of offenses for all packages would be of value to the authors.

I just posted this on atom/atom: https://github.com/atom/atom/issues/6617.


#9

Any ideas of what we should do when package owners are unresponsive? A lot of highly-used packages are a year old or so, and are just one-time imports from Sublime/Textmate packages that are ignored, and will stop working when the cutover happens.

Maybe there should be a common form we should use for publishing “1.0-compatible” replacements for packages?


#10

Here’s what I have been doing for packages that I use that haven’t been updated:

  1. Fork the package
  2. Build the fix myself and use apm link so that I’m protected
  3. Submit the fix as a pull request

If that doesn’t work (and so far it has, though I haven’t fixed all the packages I depend on yet), I’ll continue with:

  1. Open an issue and suggest that I could be added as a collaborator to merge the change (collaborators can also execute apm publish)
  2. If no response there, publish the fixed version under a new name

I haven’t thought much about what that new name would be, because I haven’t had to yet. I’d advise against putting something like “-1.0” in the title, because that always comes back to bite you.


#11

I’ve asked a similar question a few months ago. I think in this particular situation, it would make sense to delete the obsolete package from the atom website, and replace it by the new package. Not all users will necessarily look for replacements.


#12

I have been running with the --one option for several days and I have seen no difference in operation. My deprecation warning in the bottom right of the status bar shows 14 errors when booting and I’ve seen 46 after running a while. But my devtools inspector doesn’t show any problem. I expected to see a ton of exceptions.

How is --one supposed to work?


#13

If you completely exit all running instances of Atom and then start using atom --one it is supposed to remove all support for deprecated code paths. So code that calls deprecated functions should just get the “cannot read property X of undefined” exceptions. I believe that styles and such are still active and deprecated, though.


#14

It is definitely not doing that for me. I rebooted to make sure nothing was running and the started atom with --one. I got 14 deprecation warnings and the only message in the console was Window load time: 3281ms.

Is there some way to tell when atom thinks it is in this mode? Can I query some variable in the console?

I’ll post a copy of this issue in atom/atom.


#15

It could be that the deprecations you are running into aren’t API deprecations but things like styles, config reconfigurations and such that wouldn’t cause a crash.


#16

Hmmm. I’m running all my packages. So this means I don’t have to panic and fix all the deprecations? If there were style and/or config problems I’d think there would be noticeable problems.

I just posted https://github.com/atom/atom/issues/6861. Should I close it? Maybe the question about how to tell if it is really in the --one mode should be answered.


#17

If people want to help ensure that Atom transitions to v1.0 smoothly, there is a list of the 300 highest-impact packages that need deprecations fixed here:


#18