Wrapping 3rd Party Packages

Rationale

It is not always the case for upstream repository maintainers to comfortably merge PR to add official Meteor integration to their libraries and sometimes asking them to pull in many different files (and not just yet another package.js file for yet another another PM...) is even worse.

Everything can be done in a separate repository and its structure can be kept very lean adding only the minimum required files in order to perform some basic tests and to get the wrapper package published.

Actually the upstream code does not even need to be included for good into the repository: a temporary clone of the upstream repository inside the wrapper's one (lets say in a subfolder called upstream) is more than enough to bring the publish process to completion. ...also, the use of git submodules could make it more difficult to switch from one version to another and is in general discouraged.

Repository Structure

[To be completed]

For now refer to jspdf:core repository in case you need to handle exports with no global variables and to jspdf:autotable repository in case everything seems already exported a good way for Meteor. The difference is in the use of two files (meteor_pre.js and meteor_post.js in the former repository) to correctly pick up exported variables.

Version Bump

once you've cloned a wrapper repo the steps to update the wrapper package to a newer version should be:

• npm install
• gulp getUpstream --tag newtag
• gulp test
• gulp updateVersion --tag newtag
• gulp updateRelease --tag newtag
• git commit -am 'Bump to version newtag'
• git push
• meteor publish

Note: a system-wide installation of PhantomJS is required for the tests to work...