On February 26th GitHub introduced Atom to the world. I’ve mainly been using Vim for the last three to four years, mainly because of simplicity and definitely not because of VimScript. I’m not one of these people who write code in Vim like a pianist would play a piano, but I knew my way around the useful motions and commands.
Once I got my invite to the beta for Atom from Jon Rohan I downloaded and installed the beta. From the get go the main appeal of Atom to me, a Vim user for a number of years was the ability for me to build my own packages using CoffeeScript rather than VimScript. After getting used to how Atom works and its configuration I decided to jump in and build my first package.
The idea was simple. Display a small icon in the status bar to indicate the status of the tests within the project you are working on. Given Atom has been out only a day or two, the documentation is pretty sparse for building packages with only rough guides available. I decided the best way to start would be to look at how existing packages handle certain things. To work out how I can add entries into the status bar I looked into Atom’s own status-bar package. This lead me to being able to add the icon to the status bar and move onto the next part, running the tests.
I wanted the package to run the project tests whenever the user saved a file. I was looking for a package that subscribed the the saved file event so I could see how I can subscribe to it in my package. I remembered that the whitespace removes trailing white space characters when you save, jackpot.
I was initially just building the package for myself so I decided to have it just run rake test. This seemed like a good and simple starting point.
I added some styles to the stylesheet for the package to colour the status bar entry based on success or failure. It’s also coloured orange when running the command.
Running the rake test command is pretty straight forward when you have the entire Node.js API at your fingertips. I used the spawn function from the child process module to run the command and capture the standard output and error output.
Show failure in the status bar entry
Some people showed interest in the package so I decided the next best step would be to make it configurable for what commands are run for testing. After a couple of days thinking about the ideal solution I decided (given what is possible with the Atom configuration) to allow mappings of “files” to “commands”. The idea works by looking for a file in the project root and if that file exists run the command.
- Rakefile — This would run rake test
- Gruntfile — This would run grunt test
- script/test — This would run script/test
- script/cibuild — This would run script/cibuild
It would look for the files in order that they’re defined in the configuration. I’m continually improving this package from what I learn by building more packages. The next package I began to build was a way to show a projects build status on Travis CI.
Someone from the ##atom IRC channel on Freenode suggested I add a panel to show the output from running the tests. So I looked into the find-and-replace package to see how that created the bottom panel. I build a second view to handle the panel and added functions to update the text within the panel when the command output was capture.
You can open issues for bugs and suggestions on the GitHub repository https://github.com/tombell/test-status.
The next idea package I wanted was something to show my projects status from Travis CI. This package would be similar to my last package. I built the skeleton for the status bar entry. I made a simple TravisCi that interacts with the Travis CI API, fetching the last build status of a project and fetching the specific build matrix.
The way it works is by using the simple Git API exposed by Atom to check the origin remote URL. We check if the URL is from GitHub, either the SSH or HTTPS URL. If it is, we extract out the “name with owner” in the form tombell/tie and use this in our request to the Travis CI API.
Next I wanted to add the “build matrix” to a panel at the bottom of the editor. This meant adding a second view to display the list of builds and creating some functions to format the durations into “pretty” strings.
Finally I added a command to open the current project on the Travis CI website.
You can open issues for bugs and suggestions on the GitHub repository https://github.com/tombell/travis-ci-status.
So I highly recommend building your own Atom packages if you have any experience writing CoffeeScript (or JavaScript, you can use that for packages). The API available might not be entirely documented but there will be plenty of blog posts and guides that will begin popping up. Making it easier for people to start building all sorts of packages. I found the best way to make
A good community resource that has been created is Splitting Atoms which is going to be a good go-to resource for everything Atom related. I am hoping to contribute some package building guides to it eventually.
I’m happy to answer any questions about building Atom packages so feel free to find me in the ##atom IRC channel on Freenode, or drop me an email.
