devtools with option serialize.immutable does not deserialize state from devtools correctly (broken redux devtools "Jump" / "Revert" etc.)

[JayFoxRox]

Summary

redux-devtools provides a serialize option: https://github.com/reduxjs/redux-devtools/blob/main/extension/docs/API/Arguments.md#serialize.
You can provide the immutable-js library to the serialize.immutable field to: "automatically serialize/deserialize immutablejs via remotedev-serialize."

This works fine for serializing: redux-devtools will show ImmutableSet if zustand store was created with this option.
However, it breaks with deserializing during JUMP_TO_ACTION, REVERT and other devtools options, when used with zustand.

With zustand, the state doesn't get deserialized correctly, so the next time the store is used, the code will receive the wrong data type.
This problem does not occur with redux.

I believe this should work:

• Support for jumping to states was added in fix(middleware): jump state support in devtools #590 by @Aslemammad
• Support for devtools serialize option was added in Allow optional REDUX DEVTOOLS "options" object #540 by @marcoSven

Link to reproduction

https://github.com/JayFoxRox/zustand/tree/immutable-bug/examples/demo
All changes are in this commit: JayFoxRox@80f0765

specifically, this is using:

import { devtools } from 'zustand/middleware'

outStore = devtools(inStore, {
  serialize: {
    immutable: Immutable
  }
})

My reproduction is based on the zustand demo.
To show the problem, the number counter has been replaced by a growing Immutable.Set.
To display it, I JSON.stringify the Immutable.Set (Immutable handles JSON stringification, so it shows as array).

The demo creates 2 stores; one for redux and one for zustand; each with devtools.

The counter button has been duplicated:

• on the left there is a button for the redux store.
• on the right there is a button for the zustand store.

The stores both work until the devtools are used to jump.
When jumping, the redux store continues to work, but the zustand store breaks.
Once the state is broken, JSON stringification shows a JS object which represents the serialized JSON encoding in the redux-devtools.

Here's a video:

zustand-devtools-bug.mp4

Check List

Please do not ask questions in issues.

• I've already opened a discussion before opening this issue, or already discussed in other media.
  • (No. But reproduction provided and no questions)

Please include a minimal reproduction.

• I've added a link to a typescript playground or codesandbox with a minimal reproduction.
  • (No. GitHub repo provided instead to avoid account creation)

Please check this if you're filing an issue regarding TypeScript.

• I've read the typescript guide, in particular that create is to be used as create<T>()(...) and not create<T>(...).
  • (Exists with JS and TS; reproduction only created for JS, but real application where bug occured is TS)

[dai-shi]

@JayFoxRox Thanks for reporting!
Do you (or anyone else) know how to fix it?

[mia-trilo]

I'm running into similar issues. While I'm also using the immutable.js library, the issue doesn't seem to be related to immutable. I have custom serialize/deserialize code set up for persist but but there is no way to invoke it for redux devtools. One solution I see (I'm not familiar with the code on Redux, so it might not be possible on their end) is to allow custom serialize/deserialize hooks while interacting with the devtool so the states can be correctly reverted

[mia-trilo]

I looked into it a little bit, I think this issue could be solved by adding custom serializer/deserializer in DevtoolsOptions that is used here instead of the default parseJsonThen function.

[dai-shi]

That sounds reasonable. I wonder if you can write failing test cases first.

[mia-trilo]

Sure. Is there a particular format for the failing test cases you expect?

[dai-shi]

Please follow existing ./tests/ files.

[bojanstef]

Root cause: devtools forwards serialize to connect(), so state is serialized on the way out — but every message coming back (JUMP_TO_ACTION, JUMP_TO_STATE, ROLLBACK, __setState) is parsed by parseJsonThen with a bare JSON.parse, so the configured serialize.reviver is never applied. Time-travel then writes raw JSON into the store and anything that needs reviving (Immutable.Map here, also class instances / Map / Set) comes back as the wrong type. Redux's enhancer applies the reviver on the way in, which is why it works there.

Fix — thread the reviver into JSON.parse:

+    const reviver = (options as {
+      serialize?: { reviver?: (key: string, value: any) => any }
+    }).serialize?.reviver
@@ parseJsonThen
-const parseJsonThen = <T>(stringified, fn) => {
-    parsed = JSON.parse(stringified)
+const parseJsonThen = <T>(stringified, fn, reviver?) => {
+    parsed = JSON.parse(stringified, reviver)

…and pass reviver at the three parseJsonThen call sites. When serialize is unset, reviver is undefined and JSON.parse(s, undefined) is unchanged — no effect on the default path.

Verified: full suite green (215/215) plus a regression test in tests/devtools.test.tsx (a JUMP_TO_ACTION whose state needs a reviver now round-trips). Branch: bojanstef:fix/devtools-serialize-reviver.

Scope: this honors a user-supplied serialize.reviver (the serialize: { replacer, reviver } form). The serialize.immutable shorthand additionally needs remotedev-serialize to build the reviver from the Immutable lib (as Redux does) — happy to add that too.

I couldn't open a PR (PR creation looks limited to collaborators right now) — glad to submit it if that opens up, or you're welcome to pull the branch.

[dbritto-dev]

@bojanstef custom storage is on the user land

[bojanstef]

@dbritto-dev not persist storage

serialize is the devtools option already forwarded to connect()

the replacer runs outbound; inbound, parseJsonThen does a bare JSON.parse so the reviver is dropped

no userland hook in that path, it's zustand's own asymmetry

[dbritto-dev]

Got it

[koreahghg]

I put together a fix for this — verified against the current main (commit 34b4c42).

Root cause confirmed: parseJsonThen (used for ACTION, ROLLBACK, JUMP_TO_STATE, JUMP_TO_ACTION) always calls a bare JSON.parse(stringified), so a configured serialize.reviver never runs on incoming messages, even though it's correctly forwarded to connect() for outgoing state.

Fix: thread options.serialize.reviver (when serialize is an object) into JSON.parse at all three parseJsonThen call sites. No behavior change when serialize is unset/boolean.

Added 3 regression tests in tests/devtools.test.tsx (covers __setState, ROLLBACK, JUMP_TO_STATE). Full suite green: tsc --noEmit, eslint ., vitest run (227/227), pnpm run build all pass.

I can't open a PR directly (koreahghg does not have the correct permissions to execute CreatePullRequest — same restriction others hit above). Branch is ready here: https://github.com/koreahghg/zustand/tree/fix/devtools-serialize-reviver

Diff: koreahghg/zustand@main...fix/devtools-serialize-reviver

Happy to adjust if a maintainer wants a different approach.

[dai-shi]

#3568 is open.