Probably doing something silly, but I’m new to atom. I used the package generator which when run outputs the standard “It’s alive…” and a console log, if I edit these, save and run the command again it doesn’t update. Restarting atom works though.
That’s correct. For performance reasons, the code isn’t compiled and run every time. It is compiled the first time it is loaded and then run from memory each time until you reload Atom.
If that’s so I guess my next question is what is the optimal way to develop packages? I don’t want to restart atom every time I want to test a quick change.
There have been a number of discussions around this:
My recommendation is to embrace TDD and write tests for your code. Because the package code is loaded in a new window to run the tests, it always runs against the latest version of the code.
I can’t agree more with @leedohm. TDD is, and will probably remain, the fastest way to develop a program (not only for Atom packages).
I don’t want to restart atom every time I want to test a quick change.
A change can be small and quick to do and still can have a huge impact on the stability of a package. I know by experience that it’s impossible to keep track of every way to use a feature, let alone testing all the scenarios by hand each time I make a change. TDD forces you to think about what your package need to do and how you can be sure it succeeds.
And depending on the kind of feature you’ll use in your package you’ll be forced to reload Atom even if a hot-reload feature was available. For instance, custom elements can be registered but not unregistered, and it’s a recurrent problem for package that use them. When a package update is available and contains a change in a custom element, the update will be applied but it’s still the previous version of the custom element that will exist after the update.
Now, there’s still many ways to experiment in Atom, the devtools is probably the best place to do that. I also use a small trick in my tests so that I can play with my views or inspect them in the test runner by not using
jasmine.attachToDOM directly but rather by retrieving the
#jasmine-content div and append my views in it by hand:
Now I can isolate a test using the focused methods (
fdescribe) and observe my views in their state at the end of the test.
And in that case, when I really need to have a workspace in the DOM (which will be destroyed after the test) I generally add a
waitsFor 1000000, -> null at the end of the test so that the timeout won’t come after the default 5 seconds.
Actually, I find that it’s much more powerful than reloading Atom because I can test a change in a given state without having to manually reach it.