Depending on Other Packages


@ralphcallaway @JAStanton

I have created an npm module that allows an Atom package to depend on others.

It’s a work in progress, so all criticisms/improvements are welcome.


This is great. Your timing is bad though. I had to implement this in a package last week. My package doesn’t install the dependency so I may switch.


Kevin, do you know if the Atom team is planning on adding support for depending on other Atom packages? Is the “brute force” way what you would recommend generally for now?

I’m specifically looking to modify the UI of the tree-view sidebar, which comes in the “tree-view” package, which is bundled together with Atom by default. Upon activating, the package creates the “treeView” view object, and it would be convenient to grab that reference as opposed to walking the DOM to find it.


Take a look at the ServiceHub class and its documentation. It describes a method whereby packages can provide APIs to and consume APIs from each other. I think it is a pretty cool system.

Specifying package dependencies

It feels like we need a mechanism to depend on specific Atom packages. I.e. in package.json:

  "name": "my-package",
  "main": "./lib/my-package",
  "version": "0.0.0",
  "description": "A short description of your package",
  "activationCommands": {
    "atom-workspace": "my-package:toggle"
  "repository": "",
  "license": "MIT",
  "engines": {
    "atom": ">0.50.0"
  "dependencies": {
  "atomPackageDependencies": {
    "autocomplete-plus": ">=0.22.12"

i.e. I’m proposing extending the package.json schema to include:

  "atomPackageDependencies": {
    "autocomplete-plus": ">=0.22.12"

This would give apm and PackageManager the metadata required to install required packages (when specified). It could also be used as a hint during package activation on startup.

/cc @kevinsawicki


check out my npm module package-dependencies quoted above; it does something very similar.

Of course, since it is a separate module it doesn’t extend the schema directly, but can be used as a convenience workaround for now.

Also feel free to take code from it if you are implementing this behaviour into the default atom install, which would be even more convenient than depending on an outside module.

I have also raised issues that I have run into with my package, such as version conflicts, since all packages are stored in the same directory rather than node_module subdirectories in each package.

If nothing else, we can use atom-package-dependencies as a starting point for discussion on this.


@travs Nice! Yes, perhaps we should look into upstreaming this into


:+1: Travs Depending on Other Packages


EDIT UPDATE: this is resolved. But leaving in case someone errors and searches. Great job @travs!

@travs It looked good but I get an error on install:

TypeError: path must be a string
  at TypeError (native)
  at Object.fs.openSync (fs.js:455:18)
  at Object.module.(anonymous function) [as openSync] (c:\Users\basaratsyed\AppData\Local\atom\app-0.172.0\resources\atom\common\lib\asar.js:422:20)
  at Object.fs.readFileSync (fs.js:313:15)
  at Object.fs.readFileSync (c:\Users\basaratsyed\AppData\Local\atom\app-0.172.0\resources\atom\common\lib\asar.js:329:27)
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\index.js:76:30
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\index.js:69:5
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\node_modules\witwip\witwip.js:51:23
  at find (c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\node_modules\witwip\witwip.js:95:12)
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\node_modules\witwip\witwip.js:106:16
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\node_modules\witwip\node_modules\read-package-json\read-json.js:80:40
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\node_modules\witwip\node_modules\read-package-json\read-json.js:128:48
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\node_modules\witwip\node_modules\read-package-json\node_modules\graceful-fs\graceful-fs.js:170:5
  at c:\Users\basaratsyed\.atom\packages\atom-typescript\node_modules\atom-package-dependencies\node_modules\witwip\node_modules\read-package-json\node_modules\graceful-fs\graceful-fs.js:179:5
  at fs.js:295:14
  at Object.oncomplete (fs.js:93:15)

More :

Ok to use grammar.cson for just file assoc…?

Note that the issue @basarat was facing has since been resolved!


while I certainly like your npm module package-dependencies, how about getting this functionality in the core. This really should be in the core, package authors should not be required to npm install 3rd party packages just to get a possibility to specify atomPackageDependencies


Totally agree.

I raised this issue over at atom/apm already, and apparently there are similar issues in atom/core.

Since I’m not sure about the difference between “services” and “packages”, and I haven’t had much time lately to look at Atom stuff, this has gone by the wayside for me. Maybe it’s something to do with the “ServiceHub” class mentioned earlier in this thread.

Anyway, if you are interested @capaj, @joefitzgerald and anyone else, maybe we can get a little team together to do this with services.

Ping me back if you want to do this!


any updates on this? iI’m using atom 1.1 now and used the consumedServices thing with a “required”: true on the service but package only works well when i install dependencies manually :confused:


I am also wondering if this is already done or not ?

How can we tell atom to install only the dependencies ?


There currently is no support in Atom for a package to request installation of another package. A package can depend on a named and versioned “service”, but this does not force the installation of any packages.


For future visitors, we’ve created atom-package-deps and it’s pretty battle tested!


I’ve been using atom-package-dependencies, but it seems to be broken for me when using the beta version of Atom. I just get:

language-scala install failed. Output: 
/bin/sh: /Applications/Atom: No such file or directory

I guess your atom-package-deps is a better maintained replacement?


Yeah, it’s a better maintained and more fancy replacement (ie. it shows installation progress and notifications)


Awesome! I’ve already made the switch :slight_smile:


I also recently made the switch from atom-package-dependencies to Atom-Package-Deps. Aldo I preferred the way atom-package-dependencies used the same naming and property type convention in the package.json as all other package related properties, with (not yet implemented) version support. Atom-Package-Deps is just more solid and has a nice UI (configurable?) showing progress.