Decide a strategy regarding the dependencies versions

[astorije]

This ticket is to take care of our dependencies versions, i.e. deciding what versions we want to allow/rely on rather than the default generated by npm install --save[-dev]. We might want to make the decisions before fully releasing v1, to be ready with related issues from the beginning.

devDependencies

According to David, our devDependencies (mocha and morgan so far) are up-to-date.

However, (1a) I don't think we should not use * for these. That will never break the production environment and we might benefit from having them always up-to-date. Alternative: (1b) having the major version fixed (1.x.x, 2.x.x, ...).

dependencies

This is a bit more tricky. According to David, some of them are outdated (format is: version in package.json / current stable version):

• body-parser: ~1.10.1 / 1.11.0
• compression: ~1.3.0 / 1.4.0
• ejs : 1.0.x / 2.2.4
• express: ~4.10.7 / 4.11.2 (latest: 5.0.0-alpha.1)
• immutable: ~3.5.0 / 3.6.2
• promise: ~6.0.1 / 6.1.0

Regarding ejs, we are not using templates at this stage, so (2) I suggest we remove it. We'll see when we play with UI stuff.

For the other outdated dependencies, (3) I suggest that we manually review the commits that have changed (by clicking on </>) and then (4) use the x-ranges to have the major version only fixed (4.x.x). Reviewing should be useless with the semantic versioning, but it doesn't hurt to be sure.

Finally, if all the outdated dependencies go well and we have n.x.x for all of them, (5) I suggest we do the same for the up-to-date ones.

@deniak, @tripu, @plehegar, do you guys :+1: or :-1: on any of proposals (1) through (5)?

(When I say "I suggest we review...", of course I mean "I suggest I review...", but I want your approval first :-) )

[astorije]

I applied (1b) in #51, but I'll edit as you prefer.

[tripu]

I'd say:

1. a, fine with * for these.
2. OK to remove ejs if no-one is using it. The less dependencies, the better.
3. What if we simply update all dependencies to their latest minor version in package.json, and see what (if anything) breaks? If we're OK, it'd be the most time-efficient way of updating everything at once…
4. ″
5. ″

[tripu]

(Assigning to @astorije to give him the last word on this.)

[deniak]

The proposal is fine by me. jeremie++ for keeping the dependencies up-to-date

[astorije]

@tripu, with a bit of back-thinking about (1), I think I prefer (1b) because:

• consistency with the non-dev dependencies going n.x.x
• if, say, mocha upgrades its major and breaks commpatibility with our tests, we won't see it right away but only after Travis CI breaks (as no one updates its dependencies every time they push commits)

Regarding (3) through (5), hey, less work for me :+1: :-) I'll do that! We'll be that thorough when we have a userbase of several millions people and dozens of clients based on our API :)

[tripu]

After chatting with @astorije, we agreed to use n.x.x for all dependencies (both dev and prod).

[astorije]

Summary:

• (1b) (devDependencies) in a5020f6 and c6df45a
• (2) (ejs) in de4d056
• (3) through (5) (dependencies) in a2291a4

We should be all set now.