Let’s say there’s an existing JS lib that I want to wrap for Meteor use. I can’t use Npm.require/depend apparently, since I need the lib to work on both server and client, and Npm.require is for server-side only. So what’s the best practice? Do I just copy the .js file into my package dir and publish, and then I have to keep an eye out for updates so I can update my package? Or is there a better way?
You can create a git submodule in your repo that will stay in sync with the vanilla repo.
1 Like
Got it. If I go the submodule route, if people install the package I’m creating, will meteor add xyz pull all the submodule’s files, or just whatever I specify via api.addFiles? I don’t want it to pull down all the extra stuff in the repo that’s not needed.
Git submodule pulls in the remote repository completely, but meteor publish just sends those that are api.addFiles’ed to atmosphere.
2 Likes
That makes sense to have it work that way. Perfect, thanks!
BTW, what if the library uses var to define the main object I need to export? If I use submodules, I can’t just modify their code to fix the scope issue.
Hi @ffxsam,
another option is https://autopublish.meteor.com/
Here you’ll find some pointers explaining what we’re doing recently to have wrapper repositories under MeteorPackaging eve if this new approach is still to be integrated within the automated process…
There’s also an article on MeteorPedia: http://www.meteorpedia.com/read/Packaging_existing_Libraries