Is there an alternative to using `Ember.testing`?

Questions
1

Every time I need to do import Ember from 'ember' to be able to use Ember.testing in a conditional, I cringe a bit.

In an ecosystem on the fast track to Embroider, it seems a huge opportunity cost to have to import the whole Ember module as Embroider will then need to pull in everything so we can’t tree shake the unused modules.

However, for multiple scenarios, I think we still need Ember.testing. The ones I can think of (have seen) are:

  1. Setting different timeouts in tests

You don’t want to show a toast message for 2 seconds in your tests but you do in other environments.

  1. You want to be able to stub out certain 3rd party libraries in testing

The example I have at hand is having fake credit card fields (stubbing out an external js library provided by Stripe) in testing.

  1. Not integrating some providers while testing

Intercom/Zendesk/etc. is one example, I’m sure there are others.

Am I wrong in supposing that we still need Ember.testing, or that using it will prevent us from shedding unused JS modules with Embroider?

Thank you, Balint

3 Likes
2

Can you try:

import { isTesting } from '@embroider/macros';

export default class extends Component {
  this.timeout = isTesting() ? 10 : 2000;
}

I think that ought to work for you, and had nicer production + non-testing behaviors (the test code is stripped).

We need to add documentation for that method to @embroider/macros (it was added back in working on adding isTesting and isDeveloping macros by ef4 · Pull Request #493 · embroider-build/embroider · GitHub).

3 Likes
3

That’s great, I had no idea it exists, thank you!

In the project I need this in (ember-source 3.26, ember-auto-import 1.10, not using Embroider to build the project) I get an error ([Embroider:MacrosConfig] cannot read userConfigs until MacrosConfig has been finalized.) but this might have something to do with the particular setup/dependencies.

I’ll come back to this, or try it in a different project - thank you.

4

macros works without embroider. Can you say more about your setup? do you have a stack trace?

1 Like
5

@NullVoxPopuli Thank you for offering to help.

Here is the stack trace, I get this when I launch ember serve:

- stack: Error: [Embroider:MacrosConfig] cannot read userConfigs until MacrosConfig has been finalized.
    at MacrosConfig.get userConfigs [as userConfigs] (/home/balint/code/project/node_modules/@embroider/macros/src/macros-config.js:184:19)
    at getConfigForPlugin (/home/balint/code/project/node_modules/@embroider/macros/src/macros-config.js:291:28)
    at Object.get configs [as configs] (/home/balint/code/project/node_modules/@embroider/macros/src/ember-addon-main.js:89:40)
    at JSON.stringify (<anonymous>)
    at Object.buildParalleizedBabelPlugin (/home/balint/code/project/node_modules/ember-cli-htmlbars/lib/utils.js:69:70)
    at Class.included (/home/balint/code/project/node_modules/ember-cli-htmlbars/lib/ember-addon-main.js:183:52)
    at Class.superWrapper [as included] (/home/balint/code/project/node_modules/ember-cli/node_modules/core-object/lib/assign-properties.js:34:20)
    at /home/balint/code/project/node_modules/ember-cli/lib/broccoli/ember-app.js:629:15
    at Array.forEach (<anonymous>)
    at EmberApp._notifyAddonIncluded (/home/balint/code/project/node_modules/ember-cli/lib/broccoli/ember-app.js:627:25)
    at new EmberApp (/home/balint/code/project/node_modules/ember-cli/lib/broccoli/ember-app.js:137:10)
    at module.exports (/home/balint/code/project/ember-cli-build.js:29:13)
    at Builder.readBuildFile (/home/balint/code/project/node_modules/ember-cli/lib/models/builder.js:49:14)
    at Builder.setupBroccoliBuilder (/home/balint/code/project/node_modules/ember-cli/lib/models/builder.js:63:22)
    at new Builder (/home/balint/code/project/node_modules/ember-cli/lib/models/builder.js:29:10)
    at ServeTask.run (/home/balint/code/project/node_modules/ember-cli/lib/tasks/serve.js:49:7)
    at /home/balint/code/project/node_modules/ember-cli/lib/models/command.js:238:24
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async Class.run (/home/balint/code/project/node_modules/ember-cli/lib/commands/serve.js:106:5)
    at async /home/balint/code/project/node_modules/ember-cli/lib/cli/cli.js:204:32
    at async CLI.run (/home/balint/code/project/node_modules/ember-cli/lib/cli/cli.js:251:14)
    at async module.exports (/home/balint/code/project/node_modules/ember-cli/lib/cli/index.js:145:12)

ember -v gives:

ember-cli: 3.26.1
node: 14.17.0
os: linux x64

We have version 1.10.0 of ember-auto-import. Is there something else that should matter?

6

nothing jumps out at me. I’m using Ember 3.25 + ember-auto-import@^1 with embroider/macros no problem

1 Like
7

No worries, thank you for checking.

8

Maybe this exception could be caused by a particular combination of copies of @embroider/macros. You could try using yarn resolutions to force all packages to use the same version so there is only one copy.

Whatever you find out, if you can share a reproduction in an issue we’ll take a look.

1 Like
9

I’ve been trying to create a min repro of the problem and managed to have all the same versions of @embroider/macros installed in that repository:

=> Found "@embroider/macros@0.47.1"
=> Found "@embroider/core#@embroider/macros@0.33.0"
=> Found "@embroider/util#@embroider/macros@0.36.0"
=> Found "ember-cli-mirage#@embroider/macros@0.33.0"
=> Found "ember-basic-dropdown#@embroider/macros@0.41.0"
=> Found "ember-headlessui#@embroider/macros@0.41.0"
=> Found "ember-element-helper#@embroider/macros@0.39.1"
=> Found "ember-classic-decorator#@embroider/macros@0.24.1"
=> Found "ember-focus-trap#@embroider/macros@0.41.0"

This min. repro app still boots and works without any problem, however, so I wonder what else can go wrong.

Can the reason for the error be that we force version 1.10.0 (through a yarn resolution) of ember-auto-import that some dependencies don’t comply with (one requires ^1.11x, none requires version 2)?

10

That was easier to verify than I thought.

Allowing multiple (actually, just two) versions of ember-auto-import didn’t fix the issue: I’m still getting the same error as above.