pnpm peer-dependency install issue

[runspired]

I'm opening this mostly for a paper trail later for folks that hit this with ember-try. I suspect the issue is due to a project config and not with ember-try itself, but am working on validating the root cause still.

When configuring pnpm in a monorepo with workspaces, using hoist=false to guarantee isolation of packages from each other, and with strict peer dependencies turned on, ember-try scenarios may sometimes fail

ERR_PNPM_PEER_DEP_ISSUES  Unmet peer dependencies

and later

hint: If you want peer dependencies to be automatically installed, add "auto-install-peers=true" to an .npmrc file at the root of your project.
hint: If you don't want pnpm to fail on peer dependency issues, add "strict-peer-dependencies=false" to an .npmrc file at the root of your project.

Error!
1
undefined
undefined
/home/runner/work/data/data/tests/fastboot:
 ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL  [email protected] test:scenario: `ember try:one "fastboot-with-ember-fetch"`
Exit status 1
 ELIFECYCLE  Command failed with exit code 1.
Error: Process completed with exit code 1.

An example may be found here: https://github.com/emberjs/data/actions/runs/3353058316/jobs/5555616398

Note there's a bit of odd-noise involved that may hint at part of the issue, as for the blueprints package we've explicitly told pnpm via config to ignore these missing peer-deps, but this configuration is being ignored. Perhaps if we are truly running recursively as is suggested by  ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL pnpm does not see this.

 "pnpm": {
    "peerDependencyRules": {
      "ignoreMissing": [
        "@babel/core",
        "@glimmer/*",
        "ember-source",
        "@ember/string",
        "ember-inflector",
        "@ember-data/store",
        "@ember-data/tracking",
        "webpack"
      ]
    }
  },

The command in the repo that kicked this off from project root was pnpm --filter fastboot-test-app test:scenario "fastboot-with-ember-fetch" I've tried with an explicit run as well with the same result. I'm unsure currently why it thinks this is recursive.

[runspired]

It appears the issue here is at least partially this one: pnpm/pnpm#5340
Since we get a fully new lockfile with ember-try, pnpm throws. This relates to another issue with pnpm for which I have not found an open issue: once the lockfile has printed an error/warning for a missing peer-dep once, it will not do so again until significant enough changes to the lock have occurred. This means that without ember-try, this issue is not observable because the lockfile is somehow suppressing the error.

[runspired]

Looks as though the root cause here is the above plus incompatibility of fastboot with pnpm when using hoist=false. Fastboot currently expects that all whitelisted fastboot dependencies are resolvable from the parent project which may not be true if declared by an addon.

[kategengler]

Thoughts here @NullVoxPopuli ?

[NullVoxPopuli]

@runspired's investigation makes sense -- fastboot hasn't been updated in a long while, and I wouldn't put it past that project to have slightly incorrect deps.

It's a little hard to debug with the ember-data repo for me because it's big enough where it's not always clear what's a config issue and what's a pnpm issue.

minimal repos using the v2 addon blueprint are my go-to for debugging these sorts of things.