Update ci to test new versions of npm

[eriktrom]

Update ci to test new versions of npm (to verify/prevent?.peer dep, patch level drifting?) found in (some) consumers

Found via #101

• Update travis to run using npm 5.x and 6.x (thus update node)
• See if we can prevent issues like the following mkdirp: 0.5.5 #101 from happening, or somehow verify that both the lockfile and package.json are both updated
  • conversation thread within mkdirp: 0.5.5 #101 reveals the requirements for this issue. It's resolution should be checked on all relevant versions of npm that hit our target nodejs support range, which is 0.10.x...current (v14.x.x at time of this writing).\
• while addressing this issue, make sure to check that consumers of portfinder that use might use yarn at the top level of the tree (e.g., webpack, ember-cli, et al) do not vary (adding this to ci, once the problem is understood, should not be necessary, if assumptions between yarn and npm hold now and in the future 🤔)

---

quick ref:
travis build where this occured: https://travis-ci.org/github/http-party/node-portfinder/builds/673407993
issue where it is discussed at length: #101
(very likely unrelated, but leaving for future self in case): issue + pr where this is manually fixed, many months later, by human intervention: issue #108, fix #109,
- (99% un-related, but so i dont have forget): travis for #109 that passed: https://travis-ci.org/github/http-party/node-portfinder/builds/710077572 and (oddly) the previous build where it failed https://travis-ci.org/github/http-party/node-portfinder/builds/710072581

---

Master, on my computer, modified in April, not as a consumer, was correct:

cat node_modules/mkdirp/package.json
{
  "_args": [
    [
      "mkdirp@0.5.5",

&&

ls -al node_modules/mkdirp/package.json
~~ 1656 Apr 28 13:55 node_modules/mkdirp/package.json

---

[eriktrom]

a rabbit went down this hole once, i have not seen him since. anyone want to give this a shot?

[MasterOdin]

Update travis to run using npm 5.x and 6.x (thus update node)

This task is at least done. My suggestion for tackling how #101 turned out would be to see if it'd be possible to configure dependabot.yml to get what you want, where you would enable the security updates, but then configure the yml to something like:

# disable auto-created dependabot PRs, but allow security PRs
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 0
    versioning-strategy: increase

where it should now bump both package.json and package-lock.json as necessary. I'm not totally certain no this, and it is kinda hard to test unfortunately 😬

[eriktrom]

@MasterOdin - thanks for that info - i'll look at this next weekend - appreciate the input here