Updates dependencies

[jamesplease]

Updates dependencies for stuff. The only 'big' one is Underscore. Changelog here. Tests still pass 👍

Also exchanged scary >= for safe ~ for dependencies.

[rhubarbselleven]

underscore needs to go back into package.json. I've been trying to figure out howto add a testcase to ensure it stops being lost

[jamesplease]

Oh, that's pretty interesting @rhubarbselleven. I must not understand exactly how node's dependency system works...I would think that Backbone would pull it in. But you're right, I just checked and nope, it doesn't!

[jamesplease]

Added Underscore back as a dependency. Though I still don't see why Backbone didn't cause it to be installed!

[rhubarbselleven]

Sorry, I'm missing the refs off the top of my head but the collection view is where the dependency on underscore comes from. There's also a few issues floating around about package.json and underscore.

[rhubarbselleven]

It is a bit odd with the whole npm with bower thing, I've been trying to get my head around it. As essentially all build steps are performed with grunt, and bower is needed to have fetched all the dependencies - wouldn't the dependencies of package.json aka npm be just grunt and bower and the dev deps to get them running?

[cobbweb]

IMHO, we should use explicit versions or ranges... have been burnt by ~ before. Backbone doesn't follow semver. We'll see what @samccone thinks.

[samccone]

yes we happen to be using 2 libs that do not follow semvar... backbone and underscore

so we should hard lock

[Anachron]

Wait, what, Underscore and Backbone don't follow semvar? 😱

[samccone]

also coffeescript

it is a bad thing

[Anachron]

@samccone what makes you think so?
http://underscorejs.org/#changelog
http://backbonejs.org/#changelog

All of the last changes are semvar-compatibel, introducing new features with minor and no compatibility break within one major.

However, I agree on coffeescript.

[jamesplease]

Anachron: see here

[Anachron]

Thanks, didn't see that one!
The bad thing is if 90% of the project authors respect semver, but a few don't.
It screws everything up big time.

[jamesplease]

Since it doesn't follow semver, we're in a bit of a pickle. It is best to provide as large a range for the users of Marionette as possible to reduce the likelihood that they manually need to select which version of the library to include. The ~ through semver gives a reasonably large range of versions, but because these libraries don't follow semver the ranges will be arbitrary. Someone would need to manually update them to correct. Consequently the easiest thing for the developers is to just hardcode it at a single version.

Thoughts?

[disruptek]

It's not so difficult to override a dependency's package.json if you really need to -- just fork it. On the other hand, it's quite difficult to program while standing on quicksand; I'd much rather see hardcoded versions that are guaranteed to work. The BB 1.1.1 release is a disaster that Marionette has the power to sidestep. Support the lowest common denominator and allow advanced hackery by the more adventurous.

[jamesplease]

I'd much rather see hardcoded versions that are guaranteed to work.

I think we all agree on this point, @disruptek.

I'm wondering if someone should try to keep tabs on all of the versions of Backbone that Marionette supports (for the users), or if we should just hardcode the current supported version (easy for devs, worse for users).

[disruptek]

That sounds about as difficult as performing a regression test.

[rhubarbselleven]

I'd leave it as the last supported version of this project (I don't think you can specify version range, just starts getting ugly imo). Bower allows you to specify resolved dependencies as in although package X.1 requires Y.2, use Y.1 instead.

[jamesplease]

disruptek commented 4 days ago
That sounds about as difficult as performing a regression test.

I don't think that it's difficult; it's just a tedious (and important) thing to keep track of. I'm leaning toward agreeing with @rhubarbselleven and just specifying a single version.

@samccone / @cobbweb thoughts?

There are also some interesting questions raised in this comment that I'm not sure if I have a good answer to if anyone else has thoughts.

[rhubarbselleven]

A read I found whilst googling:

http://tech.pro/tutorial/1190/package-managers-an-introductory-guide-for-the-uninitiated-front-end-developer

Just like npm, Bower’s focus is on installing assets. Unlike npm, it is agnostic as it pertains to how the assets are included/required modularly in code. Npm dictates that packages follow the commonJS specification while Bower does not make any assumptions about how the assets being packaged are written or included. This also separates Bower from other current offerings that enforce a modular specification like AMD (e.g. Jam) or commonJS (e.g. browserify).

Also:

http://stackoverflow.com/questions/15092345/javascript-dependency-management-npm-vs-bower-vs-volo

To me it seems that when it comes to dependency management, package.json, bower.json and component.json (not that I've had any success in using Marionette with commonJS), should all be updated whenever there's a shift in the dependencies for Marionette.

[cobbweb]

We should at least maintain backwards compatibility with the latest few versions of Backbone/Underscore. Given this, I think for Underscore and Backbone we should specify a range.

For for Backbone we might do something like >=1.0.0 <=v1.1.1. Our other deps are safe using ~ because they semver all the things :)

[wbinnssmith]

(from my other PR adding something similar) Perhaps we could put an upper bound on the dependency? The marionette website advertises compatibility with underscore 1.4.4+. Maybe we could cap it at <= 1.7.0 for the time being?

[jamesplease]

@wbinnssmith, given that it doesn't follow semver the upper limit should probably be the most recent version of Underscore, which for now is 1.6.0. As far as we know 1.6.1 could have a completely different API that breaks all of Marionette, so it's not really even safe to set even that as a valid dependency.

I'll update this PR with some ranges for Backbone/Underscore per @cobbweb's suggestions in the AM

[samccone]

we should update the readme.md line 164-168

[samccone]

So just to be clear, this now all depends on someone running bower before building, for that reason I think we should add bower to the package.json under devDependencies.

Then in package.json we can add something like.

"scripts": {
  "bower": "./node_modules/bower/bin/bower install"
}

So an admin then only has to do something like

npm install
npm run-script bower

[jamesplease]

Good point. Would you rather this over grunt bower?

[samccone]

well ideally we would also add grunt into package.json and add something like

npm run-script grunt

This allows us to version lock grunt / bower and prevent people from needing to install things in a global scope.

[jamesplease]

👍

[samccone]

merged into v1.6.3

[cobbweb]

🎉 😄