devtools extension breaks types

[remziatay]

Bug Description

devtools extension breaks type check, allows any store type.

import { createStore } from 'zustand/vanilla';
import { devtools } from "zustand/middleware";

interface Store {
  attr: number;
  setAttr: () => void;
}

// There are no type errors -- there should be errors
createStore<Store>()(devtools(set => ({
  attr: 'string',
  setAttr: false,
})));

Works fine without the middleware

// There are type errors -- All good
createStore<Store>()(set => ({
  attr: 'string',
  setAttr: false,
}));

Reproduction Link

https://www.typescriptlang.org/play/?#code/FASwtgDg9gTgLgAgN4IMYwKYEM4YMpywYIC+CAZjFGAgOQBeArgM5xYB2AJgPQBuHIADaCstANyhIsRCk4ZehKIOakKVGgCImrDjzAhOnQRgDuWTBomh2uGOSypiBIsmAIEOODABcCdozAAIwwYCXdmDDgAQTgvXwAKAEoEAF4APgReKAMJEmBgdGxcZ0wAHhKMNKT4uQUoJWZ4gH0IxHSEeKQ3BG5uBAABOGYAWgwADwgMVDhRmCoYBGHhhAAVAAsQ4mY1qEZBTgRghBD5hA3MReWAIUZEOHPiEBV2KGO52G7PHzpWGBB2ADmtAANN1egMhqMJlMZidYJdVg8ENtdvtDsQ4QskUsEDc7kinn5Xpjuq0YnEKFhlBhQSREvSrIUcPhCGUKlVEs1WqkMp0wX1BiNxpNprNTjj1ptkTs9gcjpizlKcVFhAgAfVOJ9Yt9aL9-kDQe5wYKoSLYe8FhKkSjZei3qdscsVYI1RrSZFyd97NTaQzgEA

[dai-shi]

Can anyone look into it?

[dbritto-dev]

@dai-shi from Claude:

When you write createStore()(devtools(...)), TypeScript needs to thread Store through devtools's generic signature. But devtools infers T from the return type of the function you pass it — it doesn't receive Store as a constraint on that inner function's return. So TypeScript happily infers T = { attr: string, setAttr: boolean } from the literal, and only checks T extends Store at the outer boundary — by which point the inner initializer's object is already typed and errors are swallowed.
Without devtools, createStore() directly constrains the initializer's return type, so the mismatches surface immediately.

[remziatay]

Looks like it broke on v5.0.2 with #2875.

I can't open a PR but the fix looks pretty straightforward, it's just a missing param: https://github.com/pmndrs/zustand/compare/main...remziatay:fix-devtools-type?expand=1

[dbritto-dev]

@remziatay -> #3511

[remziatay]

Awesome! Thank you 😄

[dai-shi]

Thank you guys!

[chrisjcthomas]

This is a known behavior when combining TypeScript with Zustand's curried create or createStore creators alongside middleware.

When you use the curried creator createStore<Store>(), and pass a middleware wrapper like devtools, TypeScript defaults to an empty mutators list [] for the second generic argument. But devtools mutates the store (updating the setState signature to accept action names). The type mismatch causes TypeScript to fail to resolve the signatures correctly, causing it to fall back to any or unknown for the initializer parameter, which silently bypasses type checking on your state fields.

How to resolve:

The recommended approach in Zustand's TypeScript guide is to use the non-curried store creator syntax and explicitly define the middleware mutators as the second type parameter:

import { createStore } from 'zustand/vanilla';
import { devtools } from "zustand/middleware";

interface Store {
  attr: number;
  setAttr: () => void;
}

// Pass the devtools mutator tuple as the second generic parameter
export const store = createStore<Store, [["zustand/devtools", never]]>(
  devtools((set) => ({
    attr: 'string',   // Error: Type 'string' is not assignable to type 'number'
    setAttr: false,   // Error: Type 'boolean' is not assignable to type '() => void'
  }))
);

Why this works:

By specifying [["zustand/devtools", never]] as the second generic parameter, TypeScript understands that the devtools middleware is active and correctly type-checks the state creator arguments against your Store interface.