There aren’t a whole bunch of resources for this. Thusly it’s not too easy. If you know node then anything node related is fine. But it’s the Atom API specific bits that cause problems. You’ll likely run across something that isn’t documented, hard to follow or just plain wrong.
There is the API docs here - vital, but good luck… https://atom.io/docs/api/v1.28.0/AtomEnvironment
Defitely make use of the forum and this forum post, if you get stuck you might be able to find some discussion on it on this thread.
There are alot of threads here so here are some that I found usefull
I would start with this tutorial:
When those sources fail you, it’s time to look at other peoples packages who may have done something similar to what you’re trying do.
It’s easy to get started, because you have some decent introductory tutorials, but there is no advanced tutorials for doing anything other then the very basics.
Expect your plugin project to be alot of trial and error and hunting. In other words it’s going to be a time-consuming endeveor. But, it’s pretty cool to be able to create your own plugins in node and you’ll be able to do some pretty neat things.
Ok so with that all said, this is some notes on things that you may find useful in developing your Atom plugin.
Go to installed packages and click on “view code”.
After you make a change to your code and want to see it, you have to reload using the
window:reload command. If your used to not having to reload for dev, this is pretty darn annoiying.
Couldn’t get this package to work possibily because, as another mentions in issues, symlinking.
If anyone knows how to get a autoreload going, please let me know.
This is there by default in the package.json on the starter project and could throw you off. The idea is that you give a activation command, only after activating it does your plugin become fully accessible. So you you would toggle it to make it active and then you would have any other commands your package has would become available.
This is good for performance but very annoiying for testing. I recommend removing it out whilst working on the project and enable it for distribution. Otherwise everytime you reload, you’ll need to toggle it for your other commands to become available. Which get’s old fast.
You have global settings for your package that has a UI in the package manager, but what about if you want per project settings? Well after having a good look around the docs I couldn’t find anything. So I had a look at what other plugins did and they used a settings file that would go in a projects root folder and the plugin would look for that. They would have a global setting that would allow you to change where the file was looked for.
So you can use YML or JSON and look for that in the users root folder, load that up using node moudles. I used fs-plus and js-yaml. Take a look at my plugin wpedit for how I did this.
I couldn’t find anything on this. The basic tutorials offered take an input from the text editor. So that was pretty easy. But what if you want more? That’s more complex. I stuck to using input from the editor for my project as it make enough sense to do so.
To open the console, same as chromes console/inspector. It’s good to keep this open to see any errors.
Cmd + Opt + i
You can write to the console with
console.log too. But unless it’s to output an error, it’s best pratice to use the debugger, which you can use. When opening my file in the sources panel (
Cmd + p), there where two of it, one did not break the other did. The one that showed the full path to the file “/Users/username/.atom/packages/packagename” worked. It has
[sm] after it, if that means anything.