Using NPM packages and CommonJS modules client-side


I’m exploring options for:

  • Using client-side libraries released to the NPM repository, without needing Meteor-specific packages
  • Avoiding global, load-sequence-dependent files

I understand why Meteor has its own packaging system, but the need to find a “port” of the package on AtmosphereJS is quite limiting. Many packages are missing or out of date.

I’ve been using cosmos:browserify and meteorhacks:npm to pull down packages from NPM. This actually works pretty well, risk of duplicate libraries notwithstanding. However, even with this approach you end up with an app.browserify.js file whose job it is to put exports from modules you want to use into a global namespace.

However, I’m still uncomfortable with all my own code being in effectively “global” namespaces. I end up using blobal “master” objects that store references to key components and wrapping everything in (function() {})() type stanzas. It works, but it’s easy to make mistakes.

I’d really like to be able to write my own code using require() and have browserify (or webpack) bundle it up. I suppose that’s possible with a separate build process that just injects a single file into Meteor, but this feels brittle, and in any case wouldn’t work for code shared between client and server or accessing Meteor APIs.

So, a couple of open questions:

  • Is there a way, or plans to create a way, to modularise application code without a global namespace? When I switched my other JS projects form “global objects” to using require() and browserify, they got a lot more sane.
  • How do others manage large codebases and avoid having to carefully name files to influence the build order?


1 Like

I hope will succeed.