Understanding atom plugin architecture


#1

I would love to understand how atom implements it plugin architecture for a personal project. Does it use something like Cloud9 “architect” API or something else. what makes it so hack-able?
Would love to build something that uses this kind of architecture so a thorough understanding is needed .please help


#2

No, Atom doesn’t use Cloud9’s architect system. It uses a system that is specifically designed for Atom that is constantly being updated based on new requirements.

If you need a thorough understanding of how Atom’s package system works, you should look at the PackageManager and Package classes in Atom’s source code. At a high level, Atom packages are similar in structure to Node modules. They are installed in specific directories so that Atom can get a directory listing when it starts up and know what to load. Packages are “loaded” on Atom startup and then “activated” some amount of time after that depending on the design of the package. Atom packages can also have other metadata besides code such as stylesheets, keymaps, menus and configuration schemas. You can learn more about how to build an Atom package, which is really the beginning of understanding how it all works, in the Atom Flight Manual Hacking section.


#3

Thanks @leedohm I’l look into this.


#4

Packages are “loaded” on Atom startup and then “activated” some amount of time after that depending on the design of the package.

I wonder if it wasn’t be better to load extensions lazily like VS Code does.

Performance - Extension Activation
VS Code loads extensions as late as possible and extensions that are not used during a session are not loaded and therefore do not consume memory


#5

Atom does process packages as lazily as possible, that’s why I said:

and then “activated” some amount of time after that

When a package is “loaded” it is mostly just discovered in the file system and certain things that must be processed right away such as menus and keybindings are taken care of. By default, all packages have their activation deferred until one of their commands is executed by the user. And there are a number of other techniques that can be used to defer all or part of a package’s activation and processing until the latest possible point.

We also provide the timecop package so that package authors can take a look at their package’s loading and activation time to ensure that they are taking as little time as possible.