On Atmosphere: cosmos:browserify
On Github: cosmos-browserify
Example Meteor app using package: cosmos-browserify-example
Uses Meteor’s Npm.depends() to get the npm modules. Then uses browserify to bundle them for the client.
You may create variables which are package scoped and app (global) scoped. See the README for a complete description of how to install and use it.
Feedback is appreciated.
Hey there!
Well, this looks awesome! Just what I had been wishing for a couple of days ago when I attempted to use an npm module client-side and discovered that Meteor does not support that. I did solve my problem in some other fashion, but the next time this comes up I’ll definitely give your package a try and send more specific feedback your way (if anything comes up).
For now thanks for making & sharing the package!
Edit: And a question came up just now: So your package would probably also “pull in the world” just like plain browserify would. For example, if I use it with an npm package that depends on lodash and I already have lodash in my Meteor app, we would then have another version of lodash bundled up and delivered onto the client. Right? I suppose it might be hard or even impossible to figure out (depending on what the Meteor package API allows / exposes right now) the optimal behavior, i.e. in this case to use the already-present lodash and not bundle and distribute another lodash if the version requirements are compatible…
Though, does it really make sense, conceptually and practically, to use browserify on anything but packages with relatively small (and/or few/shared) dependencies? And thus figuring out which packages are already being shipped to the client might not even be all that important for now?
Basically just thinking out loud since there’s some things unclear for me regarding using browserify (and thus, your package), especially in conjunction with Meteor. It would be nice to have a clear understanding of how it is used most beneficially. Maybe someone who uses browserify regularly would like to express their perspective.
And this is, for me, at least, relevant to the thread’s topic because if I (and maybe others?) should come to the understanding that browserify could become a powerful tool in our Meteor-based toolbox, then it would make sense to pour some more resources into fully developing a package like cosmos:browserify into something that integrates with Meteor completely (like participating in the figuring out of versions and what to send to the client and what not which I imagine would be crucial for heavy use).
I use it to include small focused npm modules with few dependencies which are used once. So, I don’t worry about modules being included multiple times.
For an npm module which would be beneficial to multiple packages it’s better to create a Meteor package which contains it (local or published). That package can use cosmos:browserify inside it to make the npm module available.
Although it makes it easier to create a package for an npm module it’s not always necessary because some modules won’t ever be included more than once. For example, meteorhacks:flow-router uses the page module. There’s no reason for the page module to be used more than once in an app so it doesn’t need to be in its own package.
So, use cosmos:browserify to:
Browserify vs bower vs npm?
When using cosmos:browserify in an app, should app.browserify.js.cached and app.browserify.js.map be versioned or added to .gitignore?
Good question.
I think those files shouldn’t be on version control because they are generated on app startup time.
But I didn’t find about it on docs, so I’m versioning them to avoid headaches until we get an official answer.
I’ll take this example as an oficial answer:
https://github.com/elidoran/cosmos-browserify-example/tree/master/packages/browserify-example2
It’s not “gitignoring” those runtime files, but it’s not versioning them anyway.
I don’t commit them because they’re generated as part of the build process and used to avoid redoing the work when it’s unnecessary.
They’d be better placed in a ‘temp’ directory, but, I avoided that complexity and chose to place them into the package/app alongside their source file.
Meteor 1.2 eliminates the need to generate those files because its new Build API provides a caching feature.
Yes, I built it against rc 12. In the package.js file there is a line
about it: api.versionsFrom('1.2-rc.12').
I am attempting to including the vex-js package and I keep getting this error:
jQuery requires a window with a document
My packages.json file:
{
"vex-js": "2.3.3",
"jquery": "2.1.4"
}
Please post issues at the github project: cosmos:browserify.
When I put both vex-js and jquery in packges.json it finds jquery alright. Are you putting your app.browserify.js file in app/client so it isn’t used in the server scope? When I put the file in the root of the app it produces the error you mentioned.