Modularise cucumber react

[aslakhellesoy]

Summary

Ensure all components in @cucumber/react are exported and styleable

Details

This changes most components to export const SomeComponent = ... and removes the export default SomeComponent.
The motivation for this is to more easily export everything in a directory, and do it in a nested fashion.

From the consumer's perspective, this means components are now imported like this:

import { components } from '@cucumber/react'
const { DocString, Tags } = components.gherkin

This is a bit more verbose than the previous:

import { DocString, Tags } from '@cucumber/react'

But since this library has grown quite big, I feel it's a bit tidier to have a bit more namespacing rather than cramming everything into the top-level import. Trying to do that also makes it easier to forget to export something, whereas now, the various directories' index.ts spreads this responsibility over multiple files, so it's easier to spot an omission.

I've also made the <Feature> component styleable.

TODO before merging

• Make all components customisable with component overrides
• Move all styling into scss
• Get rid of all usages of components.gherkin.SomeComponent and use destructuring at the top of the file
• Change filter so we can do import { filter } from '@cucumber/react'
• Move some files around to avoid up-and-down dependencies between directories

Motivation and Context

Make sure everything is exported and make things a bit more organised

How Has This Been Tested?

With StoryBook and tsc - and existing tests are still passing.

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

• The change has been ported to Java.
• The change has been ported to Ruby.
• The change has been ported to JavaScript.
• The change has been ported to Go.
• The change has been ported to .NET.
• I've added tests for my code.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have updated the CHANGELOG accordingly.

[davidjgoss]

Looks good, agree with the approach. We could also look at enabling something like:

import { DocString } from '@cucumber/react/components/gherkin'

I think that would require us being very deliberate about the file structure of the compiled output and the .d.ts files but would probably be possible. It might come down to which (if any) is more reliable inferred by editors?

Make all components customisable with component overrides

Do we really mean every component in here? Some are a bit in flux (especially the "chrome" stuff that we have yet to restyle/redesign, plus the accordion might be replaced as you've said before) and I'd be wary of effectively expanding the public API surface more than necessary if there's not an obvious use case.

Demonstrate how to override component styles with TailwindCSS by defining classes with @apply in a Storybook story

My next task on #1592 is to add tailwind to the tooling - I can do a standalone PR for that unless you have already started?

[davidjgoss]

I think this may be used in more places than the <Feature> component?

[aslakhellesoy]

Fixed in 53cc7f6 - added a <Children> component

[aslakhellesoy]

My next task on #1592 is to add tailwind to the tooling

Ah yes, removed the tailwind TODO from this PR