Skip to content

ContextObject type definition does not match actual context object #3793

@WilcoFiers

Description

@WilcoFiers

Our ContextObject is defined as follows:

type BaseSelector = string;
type ContextObject = {
  include?: Node | BaseSelector | Array<Node | BaseSelector | BaseSelector[]>;
  exclude?: Node | BaseSelector | Array<Node | BaseSelector | BaseSelector[]>;
};

At least two of those are impossible today:

// This does not work at all. This tests the entire page:
axe.run({ include: 'main' })
// Oddly enough, this only tests `header`.
// Everything after the first string is ignored:
axe.run({ include: ['header', 'main'] })

Neither of these options is described in our docs. That makes me thing these were never supposed to work, and we created an error in the type definition. That said, we have tons of tests that do something like {include: ['#fixture']}, presumably others building on top of axe have done similar things. I don't really know why these do work. Going from the code it looks intentional. And to allow multiple strings in that array, the only change would be to change a break in a for-loop to a continue. That seems like a bug.

The way I see it, we can either change our types to what we actually support, or update what we support to match the types. I'm leaning towards the latter. It adds a little more complexity to Context, but makes them more intuitive in my opinion. If we didn't want that complexity we probably stop supporting {include: ['#fixture']}, which I'm concerned may break other implementations.

Metadata

Metadata

Assignees

Labels

coreIssues in the core code (lib/core)fixBug fixes

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions