revert on Travis: pin Node.js 10.x version to 10.0.0

[bajtos]

This partially reverts commit a36e257,
as it is no longer needed on Travis CI - the new Node.js version 10.2.0 has
fixed the problem we were experiencing on Node.js 10.1.0.

Checklist

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

[bajtos]

Looks like AppVeyor has not enabled Node.js 10.2.0 yet:

Install-Product node $env:nodejs_version
Uninstalling node 8.11.1 (x86)...
Installing node 10.1.0 (x86)...
node --version
v10.1.0
npm --version
5.6.0

Let's keep this pull request around until AppVeyor adds Node.js 10.2.0 support, at which point we can land it.

[virkt25]

LGTM once Appveyor resolves their issue

[bajtos]

Cross-posting from appveyor/ci#2276:

Is there any ETA for when Node.js 10.3.0 (or at least 10.2.0) images will be available on AppVeyor?

Will deploy it this week.

[virkt25]

AppVeyor has updated to include support 10.3.0

[bajtos]

Hmm, looks like there is some other bug on Windows, the test run freezes inside our test suite.

See https://ci.appveyor.com/project/bajtos/loopback-next/build/1.0.5656-master/job/of9c4nq2dwhhp96g

144 npm run mocha --scripts-prepend-node-path
145
146 > [email protected] mocha C:\projects\loopback-next
147 > node packages/build/bin/run-mocha "packages/*/DIST/test/**/*.js" "examples/*/DIST/test/**/*.js" "packages/cli/test/**/*.js" "packages/build/test/*/*.js"
148
149
150
151   ........................................................
152   ........................................................
153   ........................................................
154   ........................................................
155   ........................................................
156   ........................................................
157   ........................................................
158   ........................................................
159   ........................................................
160   ........................................................
161   .......................................................,
162   ........................................................
163   ........................................................
164   ........................................................
165   ........................................................
166   ........................................................
167   ..................................................

[bajtos]

I was able to reproduce the problem locally on both Node.js 10.3.0 and 10.4.0. Will investigate further.

[bajtos]

After a day of debugging, my conclusion is that this is a regression in Node.js 10.2.0. The tracking bug: nodejs/node#21210

[bajtos]

I am no longer able to reproduce the AppVeyor problem locally. Let's move this patch forward by landing only the Travis CI part.

I have also added a commit to make the tests more robust, see c283122

[shimks]

Do we know how to track when appveyor is good to be unpinned from node 10.0.0? If there isn't, we should periodically check to see if it can be reverted to latest. Otherwise, this PR LGTM

[bajtos]

Do we know how to track when appveyor is good to be unpinned from node 10.0.0? If there isn't, we should periodically check to see if it can be reverted to latest. Otherwise, this PR LGTM

I don't know about any good solution, other than open a PR to unpin 10.0.0 (as I did here) and then periodically trigger new AppVeyor run to see if the problem has been resolved. I'll open a follow-up PR.

[virkt25]

Are the timeout changes still necessary? Was it part of testing AppVeyor changes or is it intentional? I'm not opposed to them -- just curious since I've rarely run into a build failing due to a timeout (have seen it but rare).

The one marked for 15 minutes is a bit concerning ...

Can land without further review from me.

[bajtos]

Are the timeout changes still necessary? Was it part of testing AppVeyor changes or is it intentional? I'm not opposed to them -- just curious since I've rarely run into a build failing due to a timeout (have seen it but rare).

The one marked for 15 minutes is a bit concerning ...

The changes are not strictly necessary, but intentional. In the current master, the timeout was set for infinity via this.timeout(0). I used 15 minutes to give a lot of space for slow CI build machines.

[bajtos]

The follow-up pull request for AppVeyor: #1431