This fixes a few type places where you opt out of TS with 'expect-error' in the flow branch. Most are just instances of missing extends that you actually already had elsewhere. One is using an as instead of an ts-expect-error.
The problem with the expect-error is that if you miss something else you could introduce bugs since it is line level ignoring. By using an as you assert to the compiler it's getting something wrong, but in exchange the compiler trusts you and continues checking everything else that it can.
Related Issue
Link to the related issue: None
Type of Change (select one and follow subtasks)
[ ] Documentation (README.md)
[x] Maintenance or repo-level work (e.g. linting, build, tests, refactoring, etc.)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] I have included test coverage
[ ] Breaking change (fix or feature that would cause existing functionality/userland code to not work as expected)
[ ] Explain why a breaking change is necessary:
[ ] This change requires (or is) a documentation update
[ ] I have added necessary local documentation (if appropriate)
[ ] I have added necessary itty.dev documentation (if appropriate)
Description
This fixes a few type places where you opt out of TS with 'expect-error' in the flow branch. Most are just instances of missing
extendsthat you actually already had elsewhere. One is using anasinstead of ants-expect-error.The problem with the expect-error is that if you miss something else you could introduce bugs since it is line level ignoring. By using an
asyou assert to the compiler it's getting something wrong, but in exchange the compiler trusts you and continues checking everything else that it can.Related Issue
Link to the related issue: None
Type of Change (select one and follow subtasks)