hpal new affects order of deps in package.json

[devinivy]

Sometimes the adjustments to the boilerplate's package.json made by hpal new cause dependencies to appear in a different order. This isn't a huge deal, but they are no longer alphabetical, and this causes unnecessary conflicts when cherry-picking flavors.

[zemccartney]

@devinivy I had some trouble reproducing this one. Do you recall the steps / conditions under which you saw this?

Really, I just ran hpal new projy and, as far as I saw, the dependencies were listed alphabetically. My bad if those aren't the steps to reproduce and I just misread 🤡

[devinivy]

Sure! On node v10.16.3 / npm 6.13.4 when I run hpal new projy, "enter through" the npm init prompt, then inspect the package.json, I see a dependency list that looks like this:

  "dependencies": {
    "@hapi/boom": "9.x.x",
    "@hapi/joi": "17.x.x",
    "haute-couture": "3.x.x"
  },
  "devDependencies": {
    "confidence": "4.x.x",
    "@hapi/code": "8.x.x",
    "@hapi/eslint-plugin-hapi": "4.x.x",
    "@hapi/glue": "7.x.x",
    "@hapi/hapi": "19.x.x",
    "@hapi/lab": "22.x.x",
    "@hapi/eslint-config-hapi": "13.x.x",
    "dotenv": "8.x.x",
    "eslint": "6.x.x",
    "hpal": "2.x.x",
    "hpal-debug": "1.x.x",
    "toys": "2.x.x"
  }

while I would expect it to look like the dependencies verbatim from the boilerplate repo, currently:

    "@hapi/boom": "9.x.x",
    "@hapi/joi": "17.x.x",
    "haute-couture": "3.x.x"
  },
  "devDependencies": {
    "@hapi/code": "8.x.x",
    "@hapi/eslint-config-hapi": "13.x.x",
    "@hapi/eslint-plugin-hapi": "4.x.x",
    "@hapi/glue": "7.x.x",
    "@hapi/hapi": "19.x.x",
    "@hapi/lab": "22.x.x",
    "confidence": "4.x.x",
    "dotenv": "8.x.x",
    "eslint": "6.x.x",
    "hpal": "2.x.x",
    "hpal-debug": "1.x.x",
    "toys": "2.x.x"

I just determined that I do not see the same issues in node v12, so that is probably why you didn't see any issue. Even though it works in node v12, I can't exactly prove that the current implementation should always work. I'm pretty sure that the behavior here is relying on v8 internals in some way, and that behavior may simply not be well-defined.

[zemccartney]

ohhhhh gotcha. ok, cool, that's all totally clear. my bad on not thinking to include my node / npm versions, need to fix my habits there. Thanks for all that!

[devinivy]

Resolved by #41