Best way to wrap an existing JS lib?


#1

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?


#2

You can create a git submodule in your repo that will stay in sync with the vanilla repo.


#3

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.


#4

Git submodule pulls in the remote repository completely, but meteor publish just sends those that are api.addFiles’ed to atmosphere.


#5

That makes sense to have it work that way. Perfect, thanks!


#6

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.


#7

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…


#8

There’s also an article on MeteorPedia: http://www.meteorpedia.com/read/Packaging_existing_Libraries