node-app-store-connect-api VS flow-typed

Here's a perfect example. I maintain a simple Node library designed to connect to Apple's App Store Connect API. https://github.com/dfabulich/node-app-store-connect-api

It accepts, as a parameter, an URL for Apple's REST API. My library handles authentication, and returns the parsed JSON result, with a handful of tweaks to make the API more usable in JavaScript.

Depending on which URL you request, you'll get different result object back. You could get a single object in response, or an array of objects, and the type of returned objects is different for each URL type.

How would you add TypeScript types to this API? Well, Apple provides an OpenAPI documentation of all of their URLs, which I could use to autogenerate types, but then, how would I handle all of those types in response to the user's string input?

Well, it turns out that TypeScript is so amazingly fancy that you can write very clever code to parse strings at compile time, extracting parameter types etc. from string literal types. https://lihautan.com/extract-parameters-type-from-string-lit...

The documentation explains how an API like this:

   app.get('/purchase/[shopid]/[itemid]/args/[...args]')

I'm very curious, which "Redux code" are you referring to here?

I don't think the `redux` core lib ever shipped any Flow types itself. Looking at the FlowTyped repo, I see community typedefs at https://github.com/flow-typed/flow-typed/tree/master/definit... , and the Git history suggests those were indeed written by community members.

(of course on the flip side, _I_ didn't even start learning TS myself until 2019, and goodness knows _that_ has been a lot of trial and error over time :) )

As for configurability of whether casts should error, in my experience with flow it's paradoxically riskier to rely on a type nag when refactoring an unknown "offending" type casts. I've ran into cases where upgrading flow raised a cast issue, it got "fixed" it in a way that made the type system happy, but inadvertently broke tests because falsy values are tricky like that. Here's an example where a type nag showed up for someone refactoring, they did what they thought was reasonable to silence it, and proceeded to accidentally break the entire tool (slipping through tests and code review, to boot). This happened in the flow-typed tool of all places.

The process of supporting Flow users is extremely similar to that of TypeScript. Instead of adding the definition file to "types" in package.json, make a .js.flow file alongside every .js file that is being exported (for example, if you export lib/index.js, make sure to create lib/index.js.flow with the definitions). See the docs on how to create such a definition. If you want to support Flow yourself, don't publish to flow-typed; it's mainly meant for community members to create their own types for third-party packages and publish them there.