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 https://github.com/meteor/my-package.git 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:
production
some-package
another-package
external:package
development
seed
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: https://github.com/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 ?
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://github.com/moment/moment.git
Environment dependent packages
You can use NPM package.json dependencies and devDependencies, though Meteor does this already as Sashko mentioned.
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.
Thanks @sam, mgp is the clear winner here, especially since version 1.3.0 supports branch names 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 packages.meteor.com 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 npmjs.com?
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.
we use it for all