-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This is a small guide for eveyone willing to create new PRs to get some 3rd party library officially integrated as a Meteor Package.
Eventually get one single official package for each popular 3rd party library which is automatically kept up to date with the latest release.
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!
- Ask the permissions to be alble to fork a repo on MeteorPackaging
- fork the official 3rd party library repo on MeteorPackaging
- clone the forked repo locally to your machine
- identify which brach is used for development (might be
master,devel,next,future, etc...): usually it is the one with more recent commits... - create a new
meteor-integrationbranch starting from the one identifyied at point 3) - identify the build system in use (which is usually leveraged to keep files like
bower.json,composer.json, andcomponent.jsonup to date with new releases' version...) - hook into it to automatically generate the
package.jsfile 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) - figure out wich files are to be added within the
package.jsfile (preferring source files not being minified or uglified...) - test the modified build system
- test the package locally with a simple test app
- push the new branch to the fork on Meteor Packaging
- start the PR process by creating a new pull request on the official repo for the developing branch asking to merge the
meteor-integrationbranch from the forked repo (for the OT text you might take inspiration from this page - add a reference the newly created PR on this page taking care to update its status through time.
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:
- register a new organization with a name sounding as official as possible
- add
meteorpublishto the organization's team - 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.)