Spun out from [[ https://phabricator.wikimedia.org/T311244 | T311244 Lower the Burden to Contribute to Codex ]]
### User stories
As a developer of the Codex library, I want to be able to build components slowly and iteratively, instead of needing to produce a complete, thoroughly-tested, comprehensively demoed component in a single large patch.
As a developer of the Codex library, I want to be able to submit an experimental component to the library so it can be shared and tested elsewhere as we determine the scope of the eventual full component.
As a contributor to Codex outside of the Design Systems Team, I want to be able to contribute smaller patches to the library that don't require knowing how to use Codex's testing and documentation infrastructure.
### Background
Currently, we require components to meet at least a minimum viable product scope, to be fully demonstrated on our VitePress site, and to meet test coverage standards. This can be a major burden, especially for people who don't develop the library every day.
Additionally, every component must be included in `lib.ts`, meaning it will be available on the `main` branch.
We'd like to make some updates to this infrastructure to allow for a section of "experimental" components that don't need to meet all of these standards.
---
### Acceptance criteria
Note that documenting this process will be covered in a separate task; this task only covers building out the infrastructure.
- [] Add a separate entry for experimental components, so that they are not included in Codex releases on NPM
- [] Ensure that experimental components can be viewed on the demo site, perhaps in a separate section to clearly distinguish them from ready-to-use components
- [] Determine how to set up test coverage thresholds for experimental components so that they are not required to meet the same standards as ready-to-use components