Skip to content
Luca Mussi edited this page Feb 5, 2015 · 17 revisions

This is a small guide for eveyone willing to create new PRs to get some 3rd party library officially integrated as a Meteor Package.

Aims

Eventually get one single official package for each popular 3rd party library which is automatically kept up to date with the latest release.

How

Submitting PRs directly to upstream repositories: a good strategy could be to keep PRs al lean as possible to maximize acceptance probability and eventually get the repository enabled on autopublish.meteor.com together with a working webhook!

Step by Step Guide

  1. Ask the permissions to be alble to fork a repo on MeteorPackaging
  2. fork the official 3rd party library repo on MeteorPackaging
  3. clone the forked repo locally to your machine
  4. identify which brach is used for development (might be master, devel, next, future, etc...): usually it is the one with more recent commits...
  5. create a new meteor-integration branch starting from the one identifyied at point 3)
  6. identify the build system in use (which is usually leveraged to keep files like bower.json, composer.json, and component.json up to date with new releases' version...)
  7. hook into it to automatically generate the package.js file needed for Meteor publish (you can have a look at already presented PRs on this page to get some quick example and possibly copy/paste some code)
  8. figure out wich files are to be added within the package.js file (preferring source files not being minified or uglified...)
  9. test the modified build system
  10. test the package locally with a simple test app
  11. push the new branch to the fork on Meteor Packaging
  12. start the PR process by creating a new pull request on the official repo for the developing branch asking to merge the meteor-integration branch from the forked repo (for the OT text you might take inspiration from this page
  13. add a reference the newly created PR on this page taking care to update its status through time.

Users and Organizations

At the moment we need the meteorpublish user to be registered among the maintainers of the package to be published in order for the procedure used by autopublish.meteor.com to work.

So when starting a new integration attempt you should do the following:

  1. register a new organization with a name sounding as official as possible
  2. add meteorpublish to the organization's team
  3. add also other users that might be willing to participate in keeping the package monitored and up to date (e.g., official library maintainers, other users which used to have old wrapper packages for the same library, etc.)

Clone this wiki locally