JoshuaKGoldberg / JoshuaKGoldberg/TypeStat
Rearchitecture: Type-Focused Fixers
- Dominant language
- TypeScript
- Stars
- 2.3k
- Forks
- 47
- Avg merge
- 15h 55m
- Merged PRs (30d)
- 21
Description
### Overview
I'm finding TypeStat to be suffering under its own code bloat for two major reasons:
* Many fixers partially duplicate and reimplement the same logic:
* _Searching_: finding all references to a type; finding all uses; filling in generics; ...
* _Creating_ nodes: creating a new interface; adding properties to an existing node; ...
* _Deleting_ nodes: deleting properties from an existing node; removing unused constructs; ...
* _Expanding_ types: adding in `|` union types to a declaration; adding in extra interface properties; ...
* _Narrowing_ types: switching from an `any` to a real type; removing unused `|` union types; ...
* Built-in TypeScript APIs alone are not enough to satisfy TypeStat's needs for type comparisons and mutations
* https://github.com/microsoft/TypeScript/issues/9879, my "favorite" TypeScript issue
* Instantiating new types is often difficult or impossible
### Approach
I'd like to take roughly the following rearchitecture approach:
1. Gather, for each existing _and_ proposed fixer: what are its searching, node, and type needs?
2. Searching: determine a set of common operations to be implemented as shared helpers
3. Nodes and types: determine a set of common operations that a fixer would want, to be returned by fixers
4. ~Convert fixers to using [ts-simple-type](https://github.com/runem/ts-simple-type), thereby removing the need for an "exposed" TypeScript 🎉~ No longer necessary not that `isAssignableTo` is public!
4. Have the underlying infrastructure beneath fixers receive those operations and process them into text modifications
Abstracting fixers into common operations instead of keying them into their own text printing comes with a couple of key advantages:
* Simplifying typical fixer logic to make it easier to CRUD them
* #20: making it easier to overhaul the underlying text mutator
This issue replaces the more specific #124. Long term, I'd like to turn this into some kind of monorepo where the shared helpers can be exported as a standalone package for the community. That'll be a followup issue.
Contributor guide
Assessment
This issue has not been assessed yet.