dequelabs / axe-core

Accessibility engine for automated Web UI testing
https://www.deque.com/axe/
Mozilla Public License 2.0
5.75k stars 746 forks source link

`TypeError: run is not a function` when using v4.9.1 #4458

Closed acelaya closed 3 weeks ago

acelaya commented 1 month ago

Product

axe-core

Product Version

4.9.1

Latest Version

Issue Description

Expectation

Yesterday I got dependabot PRs in a few repositories, to upgrade from v4.9.0 to v4.9.1, and they all failed with the same error.

With v4.9.0 everything works as expected.

Actual

When running tests, I get TypeError: run is not a function

How to Reproduce

It happens just by updating to v4.9.1, and trying to import and then use the run function, but you can see how I use it here https://github.com/shlinkio/shlink-frontend-kit/blob/86ad2eb395d35d57225cb0e4527282435efa6955/test/__helpers__/accessibility.ts

Additional context

You can see an example of the error here https://github.com/shlinkio/shlink-frontend-kit/actions/runs/9041997260/job/24848007149#step:5:59

Also, I'm not sure if it's related, but I use vite, vitest and react-testing-library

straker commented 1 month ago

Thanks for the issue. I'm not sure why you would be getting that error. axe does have a run function and we didn't change that. I tested 4.9.0 and 4.9.1 and both show that you can get at run from typescript.

// index.ts
import axe, { run } from 'axe-core';

console.log({ version: axe.version, run });
~ npm i axe-core@=4.9.0
~ npx ts-node index.ts                                                           
{ version: '4.9.0', run: [Function: run4] }
~ npm i axe-core@latest
~ npx ts-node index.ts                                                           
{ version: '4.9.1', run: [Function: run4] }
acelaya commented 1 month ago

I think it has something to do with how vite resolves it, because I have seamlessly updated other projects to V4.9.1, but with all the projects using vite, I'm getting this error.

I'll try to do a bit of debugging to see if I can find the root cause.

ciepol commented 1 month ago

i'm facing the same issue with vitest, also only after bumping to v 4.9.1.

created devbox with super simple example: https://codesandbox.io/p/devbox/fy3jnp?file=%2Fsrc%2FApp.test.tsx

import { run, version } from "axe-core";

it("should work with axe", () => {
  console.log({ version, run });
  expect(run).toStrictEqual(expect.any(Function));
});

all is good after switching to jest + babel.

acelaya commented 1 month ago

Yep, it doesn't seem to be something related with vite specifically, but with vitest, as I can import the run function and use it in "production" code. It only fails in tests.

I have also verified that it works if I do this:

- import { run } from 'axe-core';
- run(...);
+ import axe from 'axe-core';
+ axe.run(...);
dbjorge commented 1 month ago

git bisect shows that this was introduced by https://github.com/dequelabs/axe-core/pull/4429. Specifically, the issue was introduced when we switched to using core-js's ArrayFrom polyfill rather than our own. I suspect it's probably hitting https://github.com/vitest-dev/vitest/issues/4143 (or one of the other half-dozen vitest issues related to its custom module loader).

dbjorge commented 1 month ago

Unfortunately, it's not quite as simple as just reverting back to the old non-core-js polyfill like #4465 attempted; the previous polyfill isn't good enough for the purposes of a different compatibility issue we solves in 4.9.1 (#4428).

I'd prefer not to spend time on embedding an even more complicated polyfill of our own when there's a straightforward workaround for vitest users.

We'd love to see a fix for this and if someone proposes a solution that works for vitest and continues to let us reuse core-js's Array.from polyfill we'd be happy to review a PR, but since it seems like this is an issue on vitest's end and there's a relatively straightforward workaround, we probably won't be able to prioritize researching a fix ourselves.

acelaya commented 1 month ago

I think that's perfectly reasonable. I'm personally happy closing this, unless you think it's better to keep it open.

straker commented 3 weeks ago

Because there's a workaround and this isn't something we'll get around to working on I'm going to close.