Open runspired opened 1 year ago
It appears the issue here is at least partially this one: https://github.com/pnpm/pnpm/issues/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.
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.
Thoughts here @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.
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 failERR_PNPM_PEER_DEP_ISSUES Unmet peer dependencies
and later
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 byERR_PNPM_RECURSIVE_RUN_FIRST_FAIL
pnpm does not see this.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 explicitrun
as well with the same result. I'm unsure currently why it thinks this is recursive.