Is it just me, or should meteor's package system have a few improvements?


I ran across a few problems when using the packaging system in meteor, which is otherwise very good.

Add a git repository as a package

Would this be possible to do? Just say a git repository like and use that as a package. This would be a huge help if you wanted packages that don’t clutter atmosphere

Environment dependent packages

Say I want a package that is only on development (that is, when process.env.NODE_ENV is development). Shouldn’t there be a way to do that? My primary example is having a package which automatically seeds the database when in development, but not on production. I feel like something like this would make more sense:


Private packages

Just the ability to publish a package to the cloud, but not have others able to use or view it.


The best option here is to use submodules, or the special PACKAGE_DIRS env var, which basically lets you tell Meteor to look in a new place for packages. You could use this to have a company-wide repository of packages.

You can do this inside a package by using debugOnly and prodOnly. Basically if you make a package in your app that has the debugOnly property, then have the development dependencies in there, it should do something similar to what you want.

We currently have no plans to build this feature into the official Meteor package server.

We’re hoping to make some of this stuff easier by documenting the best approaches in the Meteor Guide:

I’ll try to make sure some of these things are described there.


Still it would be nice if we could make our own package server and have some PRIVATE_PACKAGE_SERVER env variable pointing to it for example, with some kind of auth.
Open for PRs ? :smiley:


Yeah there’s already a similar thing someone is working on: Stratosphere - private package server

There is already such an environment variable in Meteor - I think it’s PACKAGE_SERVER which is nomally set to


well, yes, but than all need to be private.
or server would need to kinda NAT to the official for all non-private.
I will check that link later.


Yeah I think the best solution at the moment is having git repositories for private packages, and including them in your app as a git submodule.


I sincerely don’t mean to troll but if you’re not opposed to using Webpack in Meteor you can get all of these things today with a couple different flavors (with any Luck MDG will roll Webpack into the build system too).

You can create your own ‘Meteor’ packages with NPM packages too, they just have to depend on the globals being there (Webpack loads after the Meteor packages anyhow so this shouldn’t be an issue).

Add a git repository as a package

This will take your package and install it directly from Git:
npm install git://

Environment dependent packages

You can use NPM package.json dependencies and devDependencies, though Meteor does this already as Sashko mentioned.

Private packages

Private package registry

The cons are that you would have to move your Meteor globals over to ES6 modules… but that will come to core sooner or later anyhow.


You should probably link to directions about how to use Webpack, if you’re going to suggest it! :]


The main projects for using Webpack are:


I believe both can use Blaze with the webpack blaze loader but the first does for sure (example app)

The first one is setup in the typical Webpack/Javascript way. You end up not dealing with Meteor directly as much. This is prob. the best bet if you’re used to using Grunt/Gulp/Webpack to build your JS projects.

The second one is tied tighter into Meteor which gives it an easier to use setup, however you might not be able to configure it as easily as the first one.

@samcorcos Just wrote up a great article using the second one and React:


y’all should look at


Thanks @sam, mgp is the clear winner here, especially since version 1.3.0 supports branch names :wink: we use it for all meteor-space packages now and it works like a charm for complex dependency setups.


I’m the creator of stratosphere. Stratosphere does indeed sync with so it will contain all non-private package (metadta) + your private ones (metadata + files).




@seba, your project is really great! But do you think it will be still required when Meteor completely switches to npm? Do you have plans to support


Thanks! I think it will have value as long as long as people use isopackages and meteor supports it.
I don’t have any plans to support NPM, since there already exist a bunch of private NPM server projects, so there’s no need for me making another one.