The Problem:
At the moment our components are stored
within the root of the yarn workspace. This
works well for the existing usage but limits
the portability of our UI components. Whilst
researching server side rendering I attempted
to load a component into a serverless function
I encountered numerous issues tied to the
combination of TypeScript and Yarn workspace.
Proposed Solution:
Extract all core and reusable components into
a new `oa-components` workspace located under
the packages directory.
This package could then be consumed by the primary
application AND additional applications, for example
a standalone serverless function to generate
server side rendered documents.
The external interface for this package would be:
1. Components imported via `import {Button} from 'oa-components'`
2. A storybook build published for external reference.
Advantages:
1. Simplify the project configuration and better align
with established patterns of Yarn Workspaces & Typescript.
2. Support additional usecases for UI components
3. Lower barrier to entry for designers/contributors looking
to make improvements and fix bugs in UI components.
4. Encourage a separation between the data layer and UI components,
which could also simplify the testing of components.
5. Move our storybook configuration closer to the components which it
aims to provide documentation for.
6. Allow us to apply more structured coding standards for components.
Disadvantages:
1. Complicates contribution for folks working across backend logic,
which would remain in the project root, whilst other changes would be
required to made in `oa-components`. Similar to the division between the
primary application and our serverless functions.
2. We would need to define a criteria of what constitutes a reusable
component vs those stateful singletons which only many sense within
the root application.
The recently introduced `.toBeInTheDocument` assertation from `@testing-library` caused the type check as part of the functions precompilation to break.
There are few interesting things here;
* That typecheck includes tests files, there aren't many of them yet, but they shouldn't be scanned as part of this flow.
* This broken change was mergeable into `master` because we do no validation on the functions before we try to deploy them. There is [a PR](https://github.com/ONEARMY/community-platform/pull/1252), which introduces a Circle CI job to validate their correctness. I would need to do some investigation to see if this would have caught the issue.
