Adapt to Node.js release schedule

[tripu]

• v4 is superseded and too old.
• v5 deprecated.
• v8 is the new LTS version.

cf github.com/nodejs/LTS

In or around 1 Apr: restart the Travis build, test & confirm, merge.

[deniak]

👍

[tripu]

Node 8 was delayed and is due today — I'll keep an eye on that.

[tripu]

@deniak, Travis CI is being silly yesterday and today, but I tested this branch locally with Node 8, and everything looks okay.

[tripu]

Travis CI is being silly yesterday and today

https://www.traviscistatus.com/incidents/bnt2wtxpgs39

[tripu]

Welcome, Travis.

[deniak]

I'm not sure if versionning package-lock.json is useful in our case. I've seen that's what is recommended but it seems to me it'll add more code to review when a package is upgraded and we do use semver already so it should be fairly easy to get back to a specific state.
Also, do you know if greenkeeper will update that file when it detects a new package release?

[tripu]

@deniak:

I'm not sure if versionning package-lock.json is useful in our case. I've seen that's what is recommended

I'm not sure either. I don't know the implications well enough. As it's recommended, I'd say let's keep it under version control for now, and see how things go (eg, what emerges as the community's default practice).

but it seems to me it'll add more code to review when a package is upgraded

I don't think we have to bother even reviewing that file, ever. Relevant changes should be in package.json anyway.

Also, do you know if greenkeeper will update that file when it detects a new package release?

Apparently, it can. I don't like the extra dependency, the additional setup it requires and the extra commit per PR it'd produce, though. Let's not use that for now?

This one and w3c/echidna#417 are ready.

[tripu]

@deniak:

“Do you know if greenkeeper will update that file when it detects a new package release?”

No, it won't.

I was testing w3c/echidna#450, and this PR doesn't touch package-lock.json.

To test it, I did this, as usual:

$ git checkout greenkeeper/ldapauth-fork-4.0.1
  ⋮
$ npm install
  ⋮

But:

$ npm list ldapauth-fork
echidna@1.12.0 /repo/echidna
└── ldapauth-fork@4.0.0  invalid
npm ERR! invalid: ldapauth-fork@4.0.0 /repo/echidna/node_modules/ldapauth-fork

So I had to do:

$ git checkout greenkeeper/ldapauth-fork-4.0.1
  ⋮
$ rm package-lock.js        # ← wipe it
  ⋮
$ npm install
  ⋮

And then it's okay:

$ npm list ldapauth-fork
echidna@1.12.0 /home/tripu/t/repo/echidna
└── ldapauth-fork@4.0.1

ie, I had to remove package-lock.json altogether in order to refresh dependencies.

This is annoying. Either we adopt greenkeeperio/greenkeeper-lockfile or we exclude package-lock.json from version control (as you suggested).

[deniak]

This is annoying. Either we adopt greenkeeperio/greenkeeper-lockfile or we exclude package-lock.json from version control (as you suggested).

@tripu I don't have a strong opinion on that. I suspect greenkeeperio will integrate to the update in the near future

[tripu]

Let's leave things as they are now, then. And we'll see.

[tripu]

@deniak, I just had a worrying suspicion, and did a test to confirm that it is real:

This branch uses versions of packages that don't even exist. See the builds: the one with Node 6 fails appropriately; the one with Node 8 ignores the changes in package.json (uses package-lock.json instead), so doesn't see changes in the dependencies, and builds okay!

So, +1 now to keep package-lock.json out of version control (>> .gitignore)!

[deniak]

@tripu ok, feel free to commit that change to .gitignore without going through a PR.