Can someone help me understand the design considerations/requirements around the typing system? #3453
Unanswered
trevor-coleman
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
tl;dr I'm looking to open a PR to improve the way that type definitions are generated for the package, and looking to get some context on how/why the types are generated the way they are.
Background
My team recently encountered an issue with
date-fns
and theimport/no-duplicates
rule ineslint-plugin-import
, where imports like this are flagged as duplicates:According to this discussion the reason they are flagged as duplicates is because all of the typescript types for the project are contained in
typings.d.ts
and declared as modules like this:This is a fairly old-school approach to types, and it would be good to modernize it, given how critical this library is. I see that the typescript migration started in 2020, and looks to be nearly complete, so I'd love to pitch in on this last part.
How the Types are Built
I took a look and the types are generated in
~/scripts/build/_lib/typings/typeScript.js
(here)It seems that the build script creates
docs.json
as a single source of truth for all types and then constructs the typescript types from that, outputting them all into~/typings.d.ts
Questions
My main questions are:
Additional notes
docs.json
-- for instance are only a specific subset of the exports that are included? or could we keep using that for flow types and just usetsc
to generate the TS types?Possible Approaches
I've been thinking a bit about this, and have thought of a couple approaches, and could use some feedback on which seems like the right way to go:
1. Fix-in-place
- least amount of change
- people already know how it works
- keeps flow and TS together in one place
- we don't move anything around
- the code is still in pure-JS so there are lots of places to introduce bugs
- it's a bit indirect, we have types, then we use this complicated machine to remove them and rebuild them from scratch somewhere else
2. Use tsc to generate the types
/build
or/lib
directory, with type definitions next to their js counterparts- will be forward compatible, as tsc will always output types idiomatically
- it's the standard way to process typescript
- changes where things live
- flow and ts using different systems, could drift apart, create future maintenance issues
Cleaner, more idiomatic. But potential to cause drift betwen flow to typescript.
Final thoughts
#2 seems like the winner to me, but this feels a bit like "fools rush in" territory, so I would love to get some input from people with more experience in the project before I get in too deep on it.
Beta Was this translation helpful? Give feedback.
All reactions