Data type normalization (long-term effort)
- Dominant language
- JavaScript
- Stars
- 20
- Forks
- 10
- PR merge metrics
- No merged PRs in 30d
Description
Currently, the UXP JS API references don't follow a standard when it comes to declaring data types. A few examples of various ways things are notated in the docs (and, "as the root", the corresponding JS type):
- `number`
- `int`
- `integer`
- `number`
- `Number`
- `Integer`
- `string`
- `string`
- `String`
- `Promise`
- (no type specified at all, "in lieu of" `void`)
- `Promise`
- `void`
While this will be a big effort to fix, it currently
- can cause a lot of confusion ("Is there a difference between these?")
- disallows for any automated processing (e.g., to generate TypeScript definitions from it)
- makes the documentation seem much less consistent (and thus, subjectively, harder to work with)
Contributor guide
Research direction
Start by inventorying the UXP JS API reference entries that use inconsistent data-type notation and compare the documented variants listed in this issue. Define the canonical type forms and update the affected documentation so equivalent JavaScript types are represented consistently and can support automated processing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100