Addon compatibility test failures since v0.32.0

Hi all, I have an addon which is tested for Embroider compatibility up to the “Embroider Safe” support level. The CI pipeline runs on a schedule every morning but has been failing since the release of Embroider v0.32.0, despite there being no changes to the codebase.

There are a few errors being thrown but I can seem to figure out what the cause could be. I’m wondering if the issues may be being caused by a bug in the latest releases of Embroider itself, or if there is something that I need to change in the test setup?

It’s also probably worth noting that the tests are passing on my local machine and so the failures seem to be restricted to just CI. I’ve also tried updating the @embroider/test-setup, but this didn’t resolve the problem.

Lastly, I wondered if #640 could potentially be related as my addon also depends on Ember Data.

Here’s a link to the first failure which occurred a few days ago, https://github.com/LexasCMS/ember-data-lexascms/runs/1453212438?check_suite_focus=true

Any help would be appreciated 🙂

[ef4]

I was right, this is due to @babel/plugin-transform-runtime. In base-64/base64.js, when supporting IE11, this use of typeof:

https://github.com/mathiasbynens/base64/blob/913b89753d99362855c71c02d04384d1d1a9c2fd/base64.js#L5

gets polyfilled because typeof needs to be extended to understand the Symbol polyfill that’s in use. After babel, it looks like this:

import _typeof from "@babel/runtime/helpers/esm/typeof";

/*! https://mths.be/base64 v1.0.0 by @mathias | MIT license */
;

(function (root) {
  // Detect free variables `exports`.
  var freeExports = (typeof exports === "undefined" ? "undefined" : _typeof(exports)) == 'object' && exports; // Detect free variable `module`.

The problem is, the import makes webpack infer that this file is an ES module, not CommonJS. Babel should have said const _typeof = require('@babel/runtime/helpers/esm/typeof') instead. But it didn’t because we have the default sourceType of "module". See also https://babeljs.io/docs/en/options#sourcetype

Because webpack thinks this is an ES module, it does not define exports, which causes the environment-detection code in base64.js to go down the wrong path.

An immediately workaround is to skip babel for base-64:

- return maybeEmbroider(app);
+ return maybeEmbroider(app, { skipBabel: [{ package: 'base-64' }] });

But that doesn’t actually help consumers of ember-data-lexascms, it’s just configuring the test suite. And we don’t want to need to tell every app that uses ember-data-lexascms to configure this themselves.

We will need to think about the best real solution here. I would prefer not to remove @babel/plugin-transform-runtime, it makes real apps significantly smaller. We could set sourceType: 'unambiguous', but that can also break, when you have a real ES module that happens to have no imports or exports, and I think it’s definitely wrong for Ember apps and addons which really truly should always be authored in ES modules and not CJS.

[ef4]

Thanks for reporting, that’s exactly why it’s good that addons test this way. 👍

Will take a look.

On Sat, Nov 28, 2020 at 8:18 AM Michael Donaldson [e-mail] wrote:

Hi all, I have an addon which is tested for Embroider compatibility up to the “Embroider Safe” support level. The CI pipeline runs on a schedule every morning but has been failing since the release of Embroider v0.32.0, despite there being no changes to the codebase.

There are a few errors being thrown but I can seem to figure out what the cause could be. I’m wondering if the issues may be being caused by a bug in the latest releases of Embroider itself, or if there is something that I need to change in the test setup?

It’s also probably worth noting that the tests are passing on my local machine and so the failures seem to be restricted to just CI. I’ve also tried updating the @embroider/test-setup, but this didn’t resolve the problem.

Lastly, I wondered if #640 https://github.com/embroider-build/embroider/issues/640 could potentially be related as my addon also depends on Ember Data.

Here’s a link to the first failure which occurred a few days ago, https://github.com/LexasCMS/ember-data-lexascms/runs/1453212438?check_suite_focus=true

Any help would be appreciated 🙂

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/embroider-build/embroider/issues/641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACN6MWBLL732FPNQEOZJQDSSD2C3ANCNFSM4UFZJVTA .