Closed astorije closed 9 years ago
I applied (1b) in #51, but I'll edit as you prefer.
I'd say:
*
for these.ejs
if no-one is using it. The less dependencies, the better.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…(Assigning to @astorije to give him the last word on this.)
The proposal is fine by me. jeremie++ for keeping the dependencies up-to-date
@tripu, with a bit of back-thinking about (1), I think I prefer (1b) because:
n.x.x
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 :)
After chatting with @astorije, we agreed to use n.x.x
for all dependencies (both dev and prod).
Summary:
devDependencies
) in a5020f6 and c6df45adependencies
) in a2291a4We should be all set now.
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
):~1.10.1
/1.11.0
~1.3.0
/1.4.0
1.0.x
/2.2.4
~4.10.7
/4.11.2
(latest:5.0.0-alpha.1
)~3.5.0
/3.6.2
~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 thex
-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 :-) )