Create private packages for your Meteor apps
Cet article a été traduit en Français sur notre blog :
Along our journey creating apps with Meteor.js, we have encountered the need to create packages to wrap together standalone and reusable parts of our apps.
Here is a brief sum up of what we learnt looking around for a private package solution.
I’m pretty sure you are used to atmospherejs.com: the official package reference for meteor js apps. On Atmosphere you can find public and open-source packages, hosted publicly on Github. Meteor CLI handles the creation of packages and publication over Atmosphere. This works very well and you can find there awesome packages for almost everything.
In some cases, you don’t want to publish the source code of your packages: you may be too shy: not confident enough in the quality of your code; your package is not generic/reusable enough; your package is your company core value; etc... So: you don’t want to open source, but you want to have the same easiness of package management that Meteor provides.
There is no perfect solution there. Here are the workarounds solutions we have found:
- If you can, write a npm package that can be private in npmjs. Using a pure Npm package wasn’t an option for us as we wanted to implement front-end and Meteor related functionalities in our packages.
- Use a local folder containing your private packages and launch meteor with the METEOR_PACKAGE_DIRS environment variable set. Using a folder containing packages (with the appropriate environment variable set) seems to be a great option but we decided not to go for it because we needed then to be sure of the configuration on team computers but also servers for production. Also, maintaining HEAD at its last version for each package seemed tedious plus we weren’t sure we would be able to set a fixed version for one package in our apps.
- Download your packages in the packages directory of your app using a tool such as mgp
- Download your packages in the packages directory of your app using git submodules
The two last options are very similar, and we went for the git way which allows precise versioning and one command line update of all packages.
We hope this reading helped you out and we would be very interested to read your comments if you came up with a better option !