You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What environment are you running QUnit in?: SpiderMonkey (mozjs 68)
It seems at some point in the past 1-2 years we broke support for SpiderMonkey. It has been a while since I've heard from anyone using QUnit there, but it is something we used to support, and I'm actually working on a side-project at the moment that uses SpiderMonkey as embedded JS engine in a C++ project (0AD), and it'd be nice to be able to use QUnit and its TAP console output there.
I've observed the following three issues so far:
console.warn is undefined.
This regressed in a recent release where we started to assume that if console is defined, that console.warn is as well. This is not true in SpiderMonkey.
setTimeout is undefined.
It looks this broke due to use of es6-promise, which assumes presence of setTimeout, unlike the rest of QUnit. The funny part is, mozjs 68 actually has native support for Promise, so the polyfill isn't actually needed. But, it seems Rollup does not support a way for a file import to execute conditionally (it always hoists them and executes all imports first). So to fix this, I'm switching the polyfil library to a simpler one, and patching it with a conditional check on the inside.
Before this commit, we always built and internally exported the polyfil and sometimes not used it. Now, we only build it if needed.
QUnit is not exported.
We used to do an unconditional export to the global object (I think?), or at least it was the fallback. The latest release (export.js) codes specifically against various module loaders, and HTML browsing contexts, but none of those match under SpiderMonkey. Let's just add a plain export to the global object as last fallback, and in QUnit 3.0 we can probaly simpify this a bit and make that the unconditional default. (Doing that today would break it by unexpectedly adding a global in Node.js contexts, which I noticed would cause at least one test failure for ourselves, and likely for end-users as well. Easy to fix, but let's reserve that for QUnit 3).
The text was updated successfully, but these errors were encountered:
…n.useFakeTimers
The Promise polyfill needs to save the unmodified reference to the
`setImmediate` function in IE, for use in `Promise._immediateFn`.
This broke in QUnit 2.14.0, with the introduction of internal Promise usage
as part of #1535.
Closes#1738.
It seems at some point in the past 1-2 years we broke support for SpiderMonkey. It has been a while since I've heard from anyone using QUnit there, but it is something we used to support, and I'm actually working on a side-project at the moment that uses SpiderMonkey as embedded JS engine in a C++ project (0AD), and it'd be nice to be able to use QUnit and its TAP console output there.
I've observed the following three issues so far:
console.warn
is undefined.This regressed in a recent release where we started to assume that if
console
is defined, thatconsole.warn
is as well. This is not true in SpiderMonkey.setTimeout
is undefined.It looks this broke due to use of es6-promise, which assumes presence of setTimeout, unlike the rest of QUnit. The funny part is, mozjs 68 actually has native support for Promise, so the polyfill isn't actually needed. But, it seems Rollup does not support a way for a file import to execute conditionally (it always hoists them and executes all imports first). So to fix this, I'm switching the polyfil library to a simpler one, and patching it with a conditional check on the inside.
Before this commit, we always built and internally exported the polyfil and sometimes not used it. Now, we only build it if needed.
QUnit is not exported.
We used to do an unconditional export to the global object (I think?), or at least it was the fallback. The latest release (export.js) codes specifically against various module loaders, and HTML browsing contexts, but none of those match under SpiderMonkey. Let's just add a plain export to the global object as last fallback, and in QUnit 3.0 we can probaly simpify this a bit and make that the unconditional default. (Doing that today would break it by unexpectedly adding a global in Node.js contexts, which I noticed would cause at least one test failure for ourselves, and likely for end-users as well. Easy to fix, but let's reserve that for QUnit 3).
The text was updated successfully, but these errors were encountered: