Port to TypeScript

[nickserv]

Do you want to request a feature or report a bug?

No

What is the current behavior?

Redux publishes a manually created index.d.ts file. This also affects reselect, redux-devtools, and redux-thunk.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar.

Explanation of why this isn't recommended: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

To summarize, type declarations should either be generated from TypeScript source code or shared in DefinitelyTyped, which allows contributors to edit the types without having to edit the original package. This can also help alleviate maintenance and versioning issues regarding Redux users that write their code in TypeScript. Many issues about TypeScript compatibility could be moved to the dedicated DefinitelyTyped community if the types were separated, and the types could have breaking changes released without interfering with non-TypeScript users.

What is the expected behavior?

Redux either removes its type declaration (should be a breaking change) and moves them to DefinitelyTyped (recommended) or is ported to TypeScript (could be difficult and requires additional maintenance, but makes the types more accurate).

Which versions of Redux, and which browser and OS are affected by this issue? Did this work in previous versions of Redux?

3.4.0+ (all versions that publish index.d.ts)

[jamestharpe]

I'd like to see redux ported to TypeScript because TypeScript is the only way to ensure types are always in sync.

Types that are always in sync prevent issues from being reported, improve the overall developer experience, and increase the overall potential for adoption of the library.

The general benefits of types are that they improve the quality and productivity of the developer experience, even for non TypeScript developers. Types help catch bugs, enable better tooling, and enhance understanding.

Types provide these benefits most effectively when they perfectly match the codebase. Leaving types to a separate community all but ensures a lag between library changes and the related type definition changes, making it an overall less effective approach to providing types and therefore lessening the overall value of the library.

Regarding effort, because TypeScript is a superset of JavaScript the code base can be converted gradually. Gradual conversion means ongoing efforts are only minimally disrupted. Converting to TypeScript can also be done as a nonbreaking change, meaning it is also less effort for developers to upgrade to.

Finally, TypeScript it's self has a vibrant community. Conversion to TypeScript may garner additional contributions to help with the effort.

[markerikson]

Relevant Twitter discussion thread:

https://twitter.com/acemarke/status/1160243663370371073

[markerikson]

@jamestharpe : realistically, Redux is not going to be ported to TS any time soon.

Tim and I don't have enough TS experience to do the porting or maintenance ourselves, and even if someone else does the work, that basically makes the code impossible for us to maintain. That's already happened over in Redux Starter Kit - it was ported by several users, and now I am effectively unable to make meaningful changes to the code myself.

[janhesters]

@markerikson Redux might be small enough to learn TypeScript 😊

That being said, I prefer types bundled with the package instead of DefinitelyTyped. The reason is simple. It's a sync issue. If the types are bundled with the package, they are usually updated with breaking changes and additions as opposed to after. I've helped moving the React Navigation types into the package for exactly that reason.

[ricokahler]

Coming from a typescript fanboy, I don’t think redux should be ported to typescript especially if the maintainers don’t have a strong TS background.

I personally think the typing should be removed from this library and moved to definitely typed. I think the community will do a great job maintaining them.

Just look at react itself. Definitely typed manages those and they’re great. Given the popularity of this library, I don’t think there will be much lag time between versions even.

[timdorr]

I've got a pretty handle on our types at this point. There are some things I would like to add (more inferred types, for instance), but those are nice-to-haves, not things that make the types unusable or inaccurate. I do get the concerns around independent versioning, but I don't think there's any particular need to update them right now, so that's not really a practical concern.

I've actually already tried this with redux-thunk and it's a complete rats nest. The linting alone was a giant hassle; other dependent packages hadn't been updated in a while and were out of compliance with the latest config. And there are a lot of things that rely on redux that are going to trip those same set of issues. It's a giant mess to unravel.

[nickserv]

Overall I think moving to DefinitelyTyped is the best option. Yes, TS generates more accurate types, but it’s too much work for Redux to migrate without a rewrite. We can improve the current state of typings by maintaining them separately. Bundling like we’re doing now is not recommended by Microsoft.

[markerikson]

@janhesters : I have learned TS.

I just don't know TS well enough to be able to do stuff like this:

redux/index.d.ts

Lines 375 to 384 in 63dda81

	export type StoreEnhancer<Ext = {}, StateExt = {}> = (
	next: StoreEnhancerStoreCreator
	) => StoreEnhancerStoreCreator<Ext, StateExt>
	export type StoreEnhancerStoreCreator<Ext = {}, StateExt = {}> = <
	S = any,
	A extends Action = AnyAction
	>(
	reducer: Reducer<S, A>,
	preloadedState?: DeepPartial<S>
	) => Store<S & StateExt, A> & Ext

or this, from Redux Starter Kit:

type CaseReducerActions<CR extends SliceCaseReducers<any, any>> = {
  [T in keyof CR]: CR[T] extends (state: any) => any
    ? PayloadActionCreator<void>
    : (CR[T] extends (state: any, action: PayloadAction<infer P>) => any
        ? PayloadActionCreator<P>
        : CR[T] extends { prepare: PrepareAction<infer P> }
        ? PayloadActionCreator<P, string, CR[T]['prepare']>
        : PayloadActionCreator<void>)
}

type NoInfer<T> = [T][T extends any ? 0 : never];
type SliceCaseReducersCheck<S, ACR> = {
    [P in keyof ACR] : ACR[P] extends {
        reducer(s:S, action?: { payload: infer O }): any 
    } ? {
        prepare(...a:never[]): { payload: O }
    } : {

    }
}

[ee0pdt]

For libraries that are not written in TS I’ve noticed a worrying lag in types being added to definitely typed vs maintained in the repo. I’ve also seen more bugs and errors in the typings which lead to issues getting raised in the library even though these only relate to the types.

Based on the latest JS surveys and extrapolating out I would expect that this year around 55% of JS devs will have used TS and be happy to use it again. At the point that the majority of JS devs are actually TS devs, every JS library needs to consider TS as a majority use-case. This means eventual death to any lib that does not have good typings available.

But, I do appreciate that types for non-trivial libraries are a massive undertaking so I do see why the maintainers would want to discuss this.

[oriSomething]

If the maintainers aren't TS users, I think maintaining types as part of release is problematic because:

1. It's pain releasing patch versions only because in types mistakes, I saw it a lot in immer which sometimes there where 3 releases in a row only for types fixes
2. As someone who contribute to DT, I think it's less painful than contribute to projects themselves especially when the maintainer isn't a heavy TS user
3. For popular projects, mostly DT definitions are better than project's original when it's not TS. For example, React written in Flow, but as someone who uses both Flow and TS, mostly TS definitions that created by community are superior

[jamestharpe]

Given the maintainer’s lack of interest in porting to TypeScript, I think DT is the way to go.

• Lag should be roughly the same
• Redux package size will be slightly smaller
• Fewer issues/concerns for Redux maintainers will help focus on new features

[nickserv]

It seems like moving to DefinitelyTyped is preferred by most users and maintainers.

@markerikson @timdorr How would you like to proceed? I’m thinking we could create a branch/PR that removes Redux types, then PR the Redux package types to DefinitelyTyped (may involve some extra code style and test work to meet their review criteria). Once that’s published, it should be safe to merge the removal of the declaration file as a major release (since it’s a breaking change for TypeScript users).

[markerikson]

FWIW, Daniel Rosenwasser from the TS team says they should be moved to DT:

https://twitter.com/drosenwasser/status/1160628533166628864

I personally would be in favor of moving them to DT, but I know @timdorr has expressed interest in keeping them here. So, I'll leave it up to him to decide.