---
robots: noindex, nofollow
tags: pitch, build
---
For instructions on shaping a project see here: [Shaping a Project](/kX02SXVbS6KzMOQd56i6Cg)

# Component Info JSON Files

### Problem
Components from differing authors aren't interopable between tools, tests, and docs from other frameworks.

### Appetite
Need machine readable format that describes a component.

### Solution
- getComponentInfo package
- Resolver for compose() API
- Default resolves class and function components

### Prior Art

Many tools need some machine-readable descriptions of UI components: IDEs, documentation viewers, linters, graphical design tools, etc.

There are multiple efforts in this area for web components:

- [Polymer Analyzer's analysis.json file](https://github.com/Polymer/tools/tree/master/packages/analyzer)
- [VS Code Custom Data format](https://github.com/microsoft/vscode-custom-data/tree/master/samples/webcomponents)
- https://github.com/JetBrains/web-types

There is also an effort to standardize the web component format:
- https://github.com/webcomponents/custom-elements-json

There are also many projects that use a proprietary format to describe React components:
- Power Apps
- Fabric
- FastDNA
- Stardust
- Semantic UI React

### Risks (Rabbit holes)
*From: [Rabbit hole guidance](https://basecamp.com/shapeup/1.5-chapter-06#ingredient-4-rabbit-holes)*
*Another key aspect of shaping is de-risking. This involves identifying potential issues and complications in the solution. These may be non-obvious cases where the solution doesn't work. These could be constraints from other parts of the system (dependencies or dependent code). This aspect of shaping is what typically requires the most experience and understanding of the domain. This is likely somethign we will all collectively get better at with practice.*

### Out of scope (No-gos)
*From: [No-gos guidance](https://basecamp.com/shapeup/1.5-chapter-06#ingredient-5-no-gos)*
*A key way to deal with complicated risks or issues with the solution, is to decide a particular funcionatliy is out of scope. If reducing the scope to remove a risk or issue does not prevent us from fulfilling the original problem, then it is fine. Reducing scope may require reaching out to the original customer that had the problem we are solving, or working with a representive of the customer on our team.*