Export WithImmer type

[illarionvk]

Summary

The VSCode editor reports that the inferred type is not portable and advises adding a type annotation. Typescript CLI (v4.8.4) doesn't report this as error.

The inferred type is:

UseBoundStore<WithImmer<StoreApi<AppState>>>

The AppState type is my custom type. I can import UseBoundStore and StoreApi from zustand, but WithImmer type is not exported from the immer middleware.

Could you export the WithImmer type as well?

Link to reproduction

Check List

Please do not ask questions in issues.

• I understand this is not a question.

Please fill this template if you're filling an issue regarding TypeScript.

• I've added a link to a typescript playground or codesandbox with a minimal reproduction. Or some other way of reproduction if these two don't suffice.
• I've read the typescript guide, in particular that create is to be used as create<T>()(...) and not create<T>(...).

[dai-shi]

It's actually intentional. We consider WithImmer is an internal type.
I might be missing something in the use case, though.
Can you please share typescript playground link?
Or, does it only happen locally with --declaration enabled?

[illarionvk]

I created a sandbox, but it doesn't surface the TS2742 error:

https://codesandbox.io/s/zustand-immer-ts2742-ybm9kn?file=/src/App.tsx

After reading the discussion in Typescript issue 29808, I resolved the error by directly importing the Draft type from the immer package in my file:

export type { Draft } from 'immer'

I re-export the type to avoid 'unused type' ESLint warnings

From my personal experience, I'd prefer all inferred types to be importable so I can explicitly declare what type I expect for my variable.

Could you please make WithImmer type public if it makes sense from the library standpoint?

Middleware type declaration uses Draft type from immer

[dai-shi]

Please also see #930 discussion.
But is this specific to immer middleware which import a type from outside? 🤔

[pedroscosta]

Reopening this discussion, because it's still relevant.

Using the solution from #930 isn't ideal, because it requires every file that imports the mutated type to also import Immer and Devtools, otherwise, the type appear as never.

An example of this problem can be seen here.

Exporting the intermediary types such as WithImmer and WithDevtools fixes these problems all together and makes store typing a lot easier. So the code would look like this:

export type BluefireStore = UseBoundStore<WithImmer<WithDevtools<StoreApi<BluefireState>>>>;

and the problem is fixed:

[dai-shi]

I don't know if we would like to change types on zustand end.
This case is kind of a library use case. So, the basic idea is to define types in your library.
I'm not trying to convince you. But, what I would do would be something like this:

type SetStateWithImmer<T> = (
  nextState: T | Partial<T> | ((state: Draft<T>) => void),
  replace?: boolean
) => void;

export type BluefireStore = UseBoundStore<
  Omit<StoreApi<BluefireState>, 'setState'> & {
    setState: SetStateWithImmer<BluefireState>
  }
>;

I'm not sure I want to expose devtools types in BluefireStore. (devtools shouldn't be enabled in production?)
WithImmer is over complicated for this case and we don't consider it a public api at the moment (can change in the future.) SetStateWithImmer could be exposed from zustand.

[pedroscosta]

In my personal opinion, exporting all types is a a good practice, except when they are strictly for internal use (which doesn't seem to be the case here for zustand), because it reduces boilerplate typing for people using the package. But I completely understand your point.

In this particular case, I wouldn't export SetStateWithImmer from this package because whoever is using that shouldn't be creating a store, because this is an API for extensions, even if they did, they would have no need (or means) to export their store to any another extension.

Nonetheless, exporting some types like SetStateWithImmer from zustand is a good step in that direction and I would be really happy to see that going forward.

[alexandrutocar]

Hey, as some have already stated, exporting WithImmer would the optimal cover for TS2742, but also useful for some who write after explicit type declarations. We all could just rewrite WithImmer ourselves as an util-type, but to do it for every project, yet alone writing a dedicated util-type library to avoid re-exports, or forking the zustand repo and patching the types to be exported, seems as requiring too much hustle for me, and for others too. If there was an easier path, the issue would likely not have been raised at all. 😅

Besides that, the type does not seem internal, as it is something we, as the end users of the library have to deal with.

[dai-shi]

Let's wait for @devanshj thoughts on it.

[devanshj]

I'll let @dai-shi decide whether to export the internal types or not (I personally am inclined to not exporting too). I'm not sure how you would solve this problem, one solution that I think might work is something like this...

// @file zustand/middleware/immer.ts

import type { Draft as _Draft } from "immer"
type Draft<T> = _Draft<T>

// ...

Maybe someone can try it out and send a PR if it works.

[Cow258]

Here are the guide for use immer with zustand in JSDoc without using WithImmer

/**
 * @typedef YourStoreTypes
 * @property {Object} foo
 * @property {string} foo.bar
 * @property {(bar: string) => void} updateBar
 */

export const useStore = (
  /** @type {typeof create<YourStoreTypes, [["zustand/immer", never]]>} */(create)(
  immer(
    (set) => ({
      foo: {
        bar: 'bar',
      },
      updateBar: (bar) => {
        set(state => {
          state.foo.bar = bar
        })
      },
    })
  )
))

You can see more detail here
https://github.com/pmndrs/zustand/blob/main/docs/guides/typescript.md