Library packages?


#1

When making an Atom package that is a reusable UI widget (such that it is using parts of Atom’s API, so it is not just an ordinary Node package), what is the right way to organize the code?

As the creating packages tutorial explains, "main" must point to a file that defines activate(state) and optionally some other methods.

Though How To Speed Up Your Packages recommends reducing require() statements and whatnot.

So if the whole purpose of my package is to export a reusable component, should I have an index.coffee with only:

module.exports =
  activate: (state) ->

and then tell users to do require('my-module-name/lib/my-widget') or something like that?

Also, should it be "activationEvents": [] in the package.json file?


#2

I don’t see why you need to do anything but make your code a normal npm-like package. Everything in the atom api is reachable from the Atom global. You will also have access to the global variable Window so you can access the DOM.

I could be wrong since I haven’t done this myself.


#3

There isn’t a good story around library packages right now. If I were going to do something like this, I would look at how autocomplete-plus handles plugins as separate packages.


#4

@mark_hahn Sorry, when I say the Atom API, I also include recognition of the contents in the keymaps and stylesheets directories. If it were a “normal” npm package, I’m not convinced those things would get picked up.


#5

Following @leedohm’s suggestion, another package that uses a lot of sub-packages as plugins, is the Linter package, which probably had to deal with these questions, too.