Use async file operations for helpers

[colinrotherham]

This PR has now been split into two

Part 1 – #2897 Spruce up Puppeteer usage to stop timeouts, page conflicts etc
Part 2 – #2861 Use async file operations for helpers (this one)

For context, we "discover" components, examples and full page examples via directory lookups. But we also parse *.yaml files per component, building "component data" for Nunjucks macro options, examples, layouts and accessibility criteria

These are all tiny operations that quickly add up

Problem areas

1. Requesting review app pages hits *.yaml files (and directory lookups) repeatedly
2. Multiple ways to hit *.yaml files via getExamples() or getComponentData()
3. Multiple ways to check for JavaScript support via readdir() or glob() filtering

Changes to file system access

All of our test helpers are now asynchronous using the promise based Node.js file system methods

readdirSync() → readdir()
readFileSync() → readFile()
statSync() → stat()

Changes to test helper naming conventions

For consistency I've also ensured component/componentName/exampleName naming:

const component = await getComponent(componentName)

component.name
component.params
component.previewLayout
component.accessibilityCriteria

Plus the JSDoc to go with it (tiny addition, but is quite helpful)

/**
 * Component data from YAML
 *
 * @typedef {object} ComponentData
 * @property {string} name - Component name
 * @property {unknown[]} [params] - Nunjucks macro options
 * @property {unknown[]} [examples] - Example Nunjucks macro options
 * @property {string} [previewLayout] - Nunjucks layout for component preview
 * @property {string} [accessibilityCriteria] - Accessibility criteria
 */

[colinrotherham]

Converting to draft whilst I look at the various timeouts. Unblocking IO may have made Jest or Puppeteer trip over

[romaricpascal]

Thanks for splitting the commits and going through all these changes. The move to async looks good to me, I like how it feels more parallel-y with the Promise.all 🙌🏻 .

Only concern I have in that PR is the naming move from componentData to component that:

• looses the separation between the data about the component and the component itself
• makes it weird with the types of a lot of component variables being ComponentData

It feels a bit nitpicky and I'm not holding strongly to going back to componentData, but thought I'd mention it 😄

[colinrotherham]

Ha, that's fine

Consistency wise, I'm more than happy to make everything componentData

Consistency was the aim, not the name 🙌

Or rename the @typedef to Component?

[romaricpascal]

Making everything componentData makes more sense to me, as we keep the distinction from the component itself (in case we ever have tests that need to reference both).

[colinrotherham]

Making everything componentData makes more sense to me, as we keep the distinction from the component itself (in case we ever have tests that need to reference both).

@romaricpascal All sorted, now using componentData instead 🎉

[romaricpascal]

Ace! Looks all good to me, thanks for that extra pass on it 😄