Backbone.dualStorage
Backbone.dualStorage copied to clipboard
nilbus
Compiling
We should split the coffeescript components into different semantic files.
Then the Makefile should:
- Combine the coffeescript source files into a single javascript source file
- Build a minified/uglified javascript version
I was never comfortable with compiled JS in the repo. It seems to me that someone could easily submit a pull request where the .coffee and compiled .js differ (either mistakenly or maliciously) and a lazy merge could miss it. I'm a little sad GitHub removed file downloads.
At the very least a makefile should make less likely one fails to re-compile on merges :(
That's a legitimate concern. I wonder if/how other similar projects deal with that, since many include a minified version. I played with trying to get Travis-ci to run our tests, including a test that ensured the compiled javascript was matched the coffeescript, but it's more trouble than it's worth. I'm fine with leaving a minified version out.
When I first released it, lots of people requested including a .js version so they don't have to install CoffeeScript. That is also a legitimate concern, but perhaps less of a problem now that both CoffeeScript and node.js are more popular?
Interesting debate. I generally hold my breath when my asset manager combines and/or minifies my JS libraries. Deploying is often problematic or prone to catastrophic failure. In such cases, I appreciate when a vendor offers a minified version that (assuming it works) I can exclude from whatever tool I'm using locally to minify. I'd vote for including a minified version even if it had an "at your own risk" disclaimer in its header comment.
I think most people for most js libs are used to having both a minified and unminified/source version readily available. Just my $.02 as a user of dualstorage.
On Thu, Mar 28, 2013 at 1:01 PM, evantishuk [email protected]:
Interesting debate. I generally hold my breath when my asset manager combines and/or minifies my JS libraries. Deploying is often problematic or prone to catastrophic failure. In such cases, I appreciate when a vendor offers a minified version that (assuming it works) I can exclude from whatever tool I'm using locally to minify. I'd vote for including a minified version even if it had an "at your own risk" disclaimer in its header comment.
— Reply to this email directly or view it on GitHubhttps://github.com/lucian1900/Backbone.dualStorage/issues/31#issuecomment-15604336 .
@lucian1900, as committers, I think we just need to be responsible about vetting pull requests that we merge. If that means recompiling every pull request via make just to be sure, I'm willing to do that.
That is likely the best choice. Although perhaps the verification could be automated after all, I'll think about this some more.
Consider how other projects like faye do it: https://github.com/faye/faye/blob/master/package.json