Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ember-try scenarios failed after installing @ember/test-helpers@4.0.2 #1489

Closed
ijlee2 opened this issue Aug 26, 2024 · 12 comments
Closed

ember-try scenarios failed after installing @ember/test-helpers@4.0.2 #1489

ijlee2 opened this issue Aug 26, 2024 · 12 comments

Comments

@ijlee2
Copy link
Member

ijlee2 commented Aug 26, 2024

As reported in ember-intl/ember-intl#1916, when a consumer of ember-intl tried to update @ember/test-helpers to v4, they encountered the error message,

ember-intl tried to import "@ember/test-helpers" in "ember-intl/test-support/add-translations.js" from addon code, but "@ember/test-helpers" is a devDependency. You may need to move it into dependencies.

The reason is, ember-intl (a v1 addon) hadn't declared @ember/test-helpers as a (peer) dependency. I can verify this assumption in ember-intl/ember-intl#1918, but the fix can't be released because several ember-try scenarios for ember-intl failed with another error (CI run):

> test-app-for-ember-intl@1.3.18 test /home/runner/work/ember-intl/ember-intl/tests/ember-intl
> ember test --test-port=0

not ok 1 Chrome 127.0 - [124 ms] - Acceptance | smoke-tests > de-de: We can see translations
    ---
        actual: >
            null
        stack: >
            Error: You must set up the ember-test-helpers environment with either `setResolver` or `setApplication` before running any tests.

Could you tell me what the error message wants me to do? Is this perhaps a bug in @ember/test-helpers@4.0.2?

@NullVoxPopuli
Copy link
Collaborator

Do you have multiple copies of @ember/test-helpers in your dep graph?
ember-qunit is what provides setupApplicationTest (and friends) -- what you need to use to ultimately call setResolver / setApplication -- and ember-qunit has a peer range on test-helpers using >= -- so try out pnpm dedupe and/or post back here with pnpm why @ember/test-helpers -r

@elwayman02
Copy link
Contributor

Related issue, but I filed it separately so this ticket can focus on the setResolver bug: #1490

@NullVoxPopuli
Copy link
Collaborator

Do your tests happen to run against embroider optimized?

@LucasHill
Copy link

I'm encountering this error with ember-intl in my project when i upgrade to v4 ember test helpers.

@NullVoxPopuli
Copy link
Collaborator

I believe we're waiting on: #1486
Which is, in turn, waiting on embroider-build/embroider#2075

@ijlee2
Copy link
Member Author

ijlee2 commented Aug 29, 2024

Hi, @NullVoxPopuli .

try out pnpm dedupe and/or post back here with pnpm why @ember/test-helpers -r

I already use dedupe when updating dependencies. Here is the output for why:

Output
❯ pnpm why @ember/test-helpers -r
Legend: production dependency, optional only, dev only

docs-app-for-ember-intl@1.3.12 /ember-intl/docs/ember-intl

devDependencies:
@ember/test-helpers 4.0.2
ember-cli-addon-docs 7.0.1
├─┬ ember-data 5.3.8 peer
│ └── @ember/test-helpers 4.0.2 peer
└─┬ ember-keyboard 8.2.1
  └── @ember/test-helpers 4.0.2 peer
ember-data 5.3.8
└── @ember/test-helpers 4.0.2 peer
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-app@1.0.11 /ember-intl/docs/my-app

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-app-with-fallbacks@1.0.3 /ember-intl/docs/my-app-with-fallbacks

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-app-with-lazy-loaded-translations@1.1.0 /ember-intl/docs/my-app-with-lazy-loaded-translations

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-app-with-namespace-from-folders@1.0.8 /ember-intl/docs/my-app-with-namespace-from-folders

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-classic-app@1.1.7 /ember-intl/docs/my-classic-app

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-classic-app-with-lazy-loaded-translations@1.0.0 /ember-intl/docs/my-classic-app-with-lazy-loaded-translations

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-v1-addon@1.0.10 /ember-intl/docs/my-v1-addon

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-v1-engine@1.0.8 /ember-intl/docs/my-v1-engine

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

my-v2-addon@1.0.11 /ember-intl/docs/my-v2-addon

devDependencies:
@ember/test-helpers 4.0.2

ember-intl@7.0.5 /ember-intl/packages/ember-intl

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

test-app-for-ember-intl@1.3.18 /ember-intl/tests/ember-intl

devDependencies:
@ember/test-helpers 4.0.2
ember-qunit 8.1.0
└── @ember/test-helpers 4.0.2 peer

Do your tests happen to run against embroider optimized?

In the aforementioned CI run, the following had failed:

  • ember-lts-3.28
  • ember-lts-4.12
  • ember-lts-5.4
  • ember-lts-5.8
  • ember-beta
  • ember-canary

(embroider-optimized had passed.)

I tried downgrading @ember/test-helpers to 3.3.1 in the test app. ember-lts-3.28 would fail due to Could not find module @ember/renderer imported from @ember/test-helpers, and the lint script would fail due to type errors. (CI run, ember-try config for 3.28)

@mkszepp
Copy link

mkszepp commented Aug 31, 2024

@ijlee2 embroider fix is published... maybe your issue is now resolved

@ijlee2
Copy link
Member Author

ijlee2 commented Sep 2, 2024

@mkszepp Thanks for letting me know.

I'm still getting issues after updating @embroider/* to the latest, so I think there may need to be a fix from @ember/test-helpers.

https://github.com/ember-intl/ember-intl/actions/runs/10662230469

@mkszepp
Copy link

mkszepp commented Sep 2, 2024

@ijlee2 yes i haven seen the same issue in ember-power-select...

I have tested today using strict v4.0.0 (instead of 4.0.2) see In this case my issue for ember v3.28 is still present, but for 4.4... it was solved...

It looks like the adding externals in test-helpers was at the begin good, because it has solved embroider-safe, but now after the embroider fix was released, maybe its not anymore necessary and is causing an other issue...

@NullVoxPopuli
Copy link
Collaborator

ould fail due to Could not find module @ember/renderer imported from @ember/test-helpers,

You'll want to upgrade your @embroider/* deps - pnpm update @embroider/* -r

script would fail due to type errors

test-helpers does not support TS < 5 -- which versions are you using?

3.28

test-helpers v3.2.1 can still be used


Related -- I find that when I'm in a bit of a dependency snaffu, I'll try out pnpm's slower

shared-workspace-lockfile=false

which better isolates dependencies from the different packages in your repo.

Additionally, with wide-peer-support in libraries comes some fun problems -- we often need to use injected dependencies to get peers resolving correctly (ie: not resolving dev deps).

@ijlee2
Copy link
Member Author

ijlee2 commented Sep 9, 2024

Additionally, with wide-peer-support in libraries comes some fun problems -- we often need to use injected dependencies to get peers resolving correctly (ie: not resolving dev deps).

@NullVoxPopuli What fixed the ember-try issue for me was to add dependenciesMeta.injected. (ember-intl/ember-intl@20d19b3)

I'm not sure yet if we should be encouraging people to use an opt-in feature in pnpm (what about npm and yarn users?), because (1) ember-try for ember-intl worked fine with @ember/test-helpers@3.3.1, and (2) other v2 addons that I maintain have been working fine without dependenciesMeta.injected in the test-app (where ember-try is run also).

Anyway, I can close this issue now. I appreciate your help. ✨

@ijlee2 ijlee2 closed this as completed Sep 9, 2024
@gossi
Copy link

gossi commented Oct 10, 2024

I can across the same error message, when migrating our huge monorepo from yarn -> pnpm:

Error: You must set up the ember-test-helpers environment with either `setResolver` or `setApplication` before running any tests.

I'm posting the solution here, as this is the first result, when googling for the error message.

The reason for the error is, that two (or more) copies of @ember/test-helpers exists (as per pnpm peer resolving algorithm).

The solution requires one copy of @ember/test-helpers (it is a singleton instance). The obvious point is to remove version duplicates. pnpm/pnpm#2443 has quite some ideas so here is what I did to do that:

  • 😐 pnpm dedupe -> run it often, but no effect for the problem described here

  • 😐 pnpm up -r -> nice cleanup but no effect (still valuable)

  • 😐 Use syncpack -> cool tool; does help reduce duplicates, but not for @ember/test-helpers

  • ✅ Use pnpm.overrides - that helped to reduce @ember/test-helpers from 3 to 2 instances 🙌🥳 I can't really say anymore, which dependency was helping at the end, but here is the ones I did used in :

    {
      "pnpm": {
        "overrides": {
          "@babel/core": "^7.25.7",
          "@babel/eslint-parser": "^7.25.7",
          "@babel/runtime": "^7.25.6",
          "@ember/test-helpers": "^4.0.4",
          "@embroider/util": "^1.13.2",
          "@glimmer/global-context": "^0.92.3",
          "@glimmer/interfaces": "^0.92.3",
          "@glimmer/reference": "^0.92.3",
          "@glimmer/syntax": "^0.92.3",
          "@glimmer/util": "^0.92.3",
          "@glimmer/validator": "^0.92.3",
          "@glint/core": "^1.4.0",
          "@glint/template": "^1.4.0",
          "@glint/environment-ember-loose": "^1.4.0",
          "babel-loader": "^9.2.1",
          "broccoli-funnel": "^3.0.8",
          "ember-cli-babel": "^8.2.0",
          "ember-cli-htmlbars": "^6.3.0",
          "ember-cli-typescript": "^5.3.0",
          "ember-source": "~5.12.0",
          "rsvp": "4.8.5",
          "terser-webpack-plugin": "^5.3.10",
          "typescript": "^5.6.2",
          "webpack": "^5.95.0"
        }
      }
    }

    The version numbers are up-to-date for the time writing this, also as a context, the app is on ember-source@5.12. The choice of packages is more important than the versions. I found them by skimming through pnpm-lock.yaml and looking for obvious duplicates in there (especially ember related packages).

  • Tried various settings for .npmrc, that DO NOT help:

    • hoist=false
    • hoist-workspace-packages=false
    • auto-install-peers=false
    • resolve-peers-from-workspace-root=false
    • => Ember recommends the latter two already so they were turned on "naturally"

I still needed to get rid of one copy for @ember/test-helpers and none of these settings helped, so I was manually following the dependencies in pnpm-lock.yaml. Looking for @ember/test-helpers reveals the two instances being installed. I showcase the diff here:

+ '@ember/test-helpers@4.0.4(@babel/core@7.25.7)(@glint/template@1.4.0)(ember-source@5.12.0(@glimmer/component@1.1.2(@babel/core@7.25.7))(@glint/template@1.4.0)(rsvp@4.8.5)(webpack@5.95.0(@swc/core@1.7.35)))':
- '@ember/test-helpers@4.0.4(@babel/core@7.25.7)(@glint/template@1.4.0)(ember-source@5.12.0(@glimmer/component@1.1.2(@babel/core@7.25.7))(@glint/template@1.4.0)(rsvp@4.8.5))':
    dependencies:
      '@ember/test-waiters': 3.1.0(@babel/core@7.25.7)
      '@embroider/addon-shim': 1.8.9
      '@embroider/macros': 1.16.9(@babel/core@7.25.7)(@glint/template@1.4.0)
      '@simple-dom/interface': 1.4.0
      decorator-transforms: 2.2.2(@babel/core@7.25.7)
      dom-element-descriptors: 0.5.1
+     ember-source: 5.12.0(@glimmer/component@1.1.2(@babel/core@7.25.7))(@glint/template@1.4.0)(rsvp@4.8.5)(webpack@5.95.0(@swc/core@1.7.35))
-     ember-source: 5.12.0(@glimmer/component@1.1.2(@babel/core@7.25.7))(@glint/template@1.4.0)(rsvp@4.8.5)(webpack@5.95.0)
    transitivePeerDependencies:
      - '@babel/core'
      - '@glint/template'
      - supports-color

I used diffchecker to help me copy these snippets over to see the difference between the instances.

you might notice the addition of @swc/core for one instance.

I traced this down, ember-source -> ember-auto-import -> babel-loader|css-loader|mini-css-extract-plugin|style-loader -> webpack -> terser-webpack-plugin, and the latter looks like this:

-  terser-webpack-plugin@5.3.10(webpack@5.95.0):
+  terser-webpack-plugin@5.3.10(@swc/core@1.7.35)(webpack@5.95.0(@swc/core@1.7.35)):
    dependencies:
      '@jridgewell/trace-mapping': 0.3.25
      jest-worker: 27.5.1
      schema-utils: 3.3.0
      serialize-javascript: 6.0.2
      terser: 5.34.1
      webpack: 5.95.0(@swc/core@1.7.35)
+    optionalDependencies:
+      '@swc/core': 1.7.35

Apparently this has to do with how pnpm resolves and dedupes peers. In one package, there is a @swc/core present which leads to two instances being present. Since this is based on peer resolution, there is basically no pnpm setting I found that could help with this. After exchanging with @NullVoxPopuli he mentioned that optionalDependencies are little adventureous in pnpm. That was the right search cue for me to find this issue: pnpm/pnpm#7231 - Now it is mentioned to use .pnpmfile.cjs and "modify" dependencies on-the-fly while they are being resolved. In the end, here is mine now:

// .pnpmfile.cjs

module.exports = {
  hooks: {
    readPackage: (pkg) => {
      if (pkg.name === "terser-webpack-plugin") {
        delete pkg.peerDependenciesMeta["@swc/core"];
      }

      return pkg;
    }
  }
};

I'm removing the optional peer dependency for terser-webpack-plugin. Now that stops pnpm from its usual peer deduping and now. finally. I'm left with one copy of @ember/test-helpers and tests are running without the message initially stated in this issue.

I must say, this is quite counter-intuitive solution. I've seen some improvement for handling optional deps in pnpm (as per my research). If you come across this, there may already be another solution provided by pnpm itself. However, if not, I hope this is helpful 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants