pnpm duplicates lead to errors

[gossi]

We have a library addon, that uses getApplication() from @ember/test-helpers as part of its test-support. Tests are working fine. Used ember version is 6.3. Now renovate attempts an update of @ember/test-helpers package from v3 -> v5. This fails on ember-try with other ember versions, because getApplication() returns undefined. After a debugging session, I figured the reason for this:

Duplicate of test-helpers for the ember-5.12 scenario. Apparently both are used, one stores the application in module scope, the other is asked to return it.

It's not necessarily a problom of ember-try, but the context in which this is appearing. So I am wondering if there are some clever people, that already figured out a solution.

[kategengler]

Do you have @ember/test-helpers listed in your ember-try config at all?

If not, I would open this over on ember-test-helpers.

[gossi]

Well, I figured how to make it work. Setup is a monorepo with a v2 addon and a test-app.

The change needed is to overwrite the root package.json file and also add:

{
  "pnpm": {
    "overwrites": {
      "ember-source": "~5.12.0"
    }
  }
}

... then pnpm will not duplicate the deps here and behavior is as expected. So, same issue as in #1058

Maybe meanwhile: https://github.com/embroider-build/try this is an alternatve? (maybe for small projects, I doubt it for my case at hand).

[kategengler]

We need to decide whether that should be the solution or a setting in .npmrc. Once we do, we can make ember-try do it by default for pnpm monorepos. Thoughts @NullVoxPopuli?

[NullVoxPopuli]

There are sort of two things that need to happen in a pnpm monorepo, especially in addons that need to use macroCondition, and have a correct dep graph:

• have only one copy of ember-source in the whole monorepo (not just one version, but one physical location of ember-source)
• to force ember-source to be only one copy:
  • overrides: specific version
  • npmrc setting setting to hoist 🙈
• OR don't put ember-source as a devDep or dep (peer is fine) at all in the addon -- only define ember-source in the apps -- then you don't need to worry about overrides or hoisting or duplicates or anything like that.
  • for TS, you need to do a sneaky: point tsconfig.json#compilerOptions#types at an app's copy of ember-source, e.g.: "types": ["../test-app/node_modules/ember-source/types"]

[gossi]

The now most horrable error message of today is when using pnpm, but there is a version mismatch detected somewhere.

We learned how to deal with that, by making sure we only have one such dependency in our node modules directory. That's great for development.

The other idea is to use injected deps (eg. with pnpm-sync-dependencies-meta-injected) - but that's really annoying to have for development (it is ok in CI to check for other versions).

@NullVoxPopuli mentioned other ideas that have similar drawbacks as injected dep meta (they might be ok for CI in an ember-try run).

So it is about the tools we have and how they work with pnpm. While for some reasons injected dep meta can work, there are situations where it doesn't. Here is such a situation, where ember-try misses the adaptation to pnpm (well it was designed long before pnpm, so this is no surprise). As @NullVoxPopuli explained there only can be one version of ember-source being present, ember-try's job is explicitly to manage multiple such.

FWIW is in ember-try to have functionality to manage the tool as I would be able to do it manually (which is missing) for a given scenario - at the moment many of my projects are stuck due to that. Providing workspace overwrites seems to be the cheapest solution ?

[kategengler]

I'm happy to go either way. In one addon, I solved it by having a script run before ember-try to make the addon an injected dep just for the ember-try run. I have not yet verified that overrides works; iirc I went for injected because it did not work.