hapipal / hpal

hapi pal CLI
https://hapipal.com
MIT License
51 stars 7 forks source link

hpal new affects order of deps in package.json #38

Closed devinivy closed 4 years ago

devinivy commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Resolved by #41