Package config versus state


How is serialized state different than config storage? Is it per project or global? Under what conditions is it lost? I seem to lose state often.


I’ll try to summarize my understanding of both:


  • Used to modify the behavior of a package (enable/disable features, etc.).
  • Open to changes by the user.
  • Shared between projects/window.
  • Lost only if the user destroy its config.cson file.
  • Should be considered as a trusted source.

Serialized State:

  • Used to speed up packages activation.
  • Closed to changes by users (you are not supposed to access/edit the serialized state in storage).
  • Are created by a package on a per project basis.
  • Should never be considered as a source of trust (state data can help speed up a package startup but everything it relates to can have changed since the time it was serialized).
  • You can lose states whenever the storage dir content is discarded (there’s probably some other case that lead to a loss of state)

Hope it helps


Ah, that why it seems to be lost all the time. I thought it was global.

I used it for storing the list of recently opened files in my view-tail-large-files package which was totally wrong. And I just used it wrong in a new package I’m about to publish.

So what is the recommended method of permanent global (per computer/user) state storage? I haven’t noticed anything in the docs or in this forum.


There isn’t a built-in method for doing that. I’m pretty sure someone asked this about their package too and I believe I recommended creating a new directory under ~/.atom for it.