Package versus init.coffee customization


#1

Hello everybody,
I have a theoretical question. It is related to Atom, but I guess it also applies for any other similar system.

Scenario
An organization uses Atom as development platform. They need a wide set of new features and functionalities that has to be available to every developer in the group.

My question is: what should to be programmed in packages, and what could be placed in the init file and then distributed among developers? Could it be considered a good practice, when handling some of the functionalities is just impractical with packages?

I hope the question is clear.
Thanks!


#2

I would leave the init.coffee to the user, and only use packages.

  1. It’s simpler to handle dependencies within a package. If your feature requires some additional resources or modules you’ll be able to specify versions and such in the package.json file, while in the init.coffee you’ll have a hard time dealing with that.
  2. It’s simpler to handle updates through a package. Let’s say you go with the init.coffee approach, you will probably put that file in a CVS. Now imagine one of your developer tweak that file to add a command he regularly uses but that isn’t part of your base script, there’s a high chance that the next update turns into a conflict. With a package, still on a CVS, you can update the package without risking any conflicts. The init.coffee stay the place where a user can customize its Atom version for its own usage.
  3. It’s easier to architecture the features through packages. You define the file structure, you can expose services, you can have tests, etc. All of this is either not possible or harder to do with the init.coffee file.
  4. Packages can be deactivated and have settings. So there’s always the possibility to opt-out from the package’s feature or to tweak its settings to fit your need.
  5. Packages can serialize data, which can be handy if your feature requires to store some states between sessions.

There’s probably other points I forgot to mention but I think the list above is already enough to figure that using the init script isn’t the most convenient approach.

Hope it helps.


#3

Thank you, this makes completely sense.

I asked it because sometimes also maintaining a package can be quite an hassle. I work with some packages in my company, we have a cache for npm so these packages have to be installed with an installer (that is, another Atom package). Plus, since we’re experiencing issues with npm nested deps, we’re using a CI server to collect all the packages and create a zip file to extract in the .atom/packages folder.

Also, it’s true the init.coffee file is limited, it would have to use localStorage to save data, cannot be tested nor deactivated.

Thanks for your opinion, I’ll just drop the idea I guess!