It all started with a crash in @reown/appkit-react-native. While debugging that crash, I noticed something weird happening with valtio. The subscribe() function seemed to work fine, but proxy() wasn't behaving as expected. I decided to dig into the library code itself and added some debugging directly in node_modules/valtio/vanilla.js. @reown/appkit-react-native subscribe() proxy() node_modules/valtio/vanilla.js I printed proxyStateMap.get(proxyObject) in both functions, and that's when things got interesting: proxyStateMap.get(proxyObject) In proxy(): Got the correct value ✓
In subscribe(): Got undefined ✗ In proxy(): Got the correct value ✓ proxy() In subscribe(): Got undefined ✗ subscribe() undefined Wait, what? They were completely different WeakMap instances from different valtio module instances! The proxy object was being stored in one proxyStateMap, but when subscribe() tried to find it, it was looking in a completely different proxyStateMap from a different valtio instance. That's like putting your keys in one drawer and looking for them in another. completely different WeakMap instances proxyStateMap subscribe() proxyStateMap A Quick Note on Debugging Library Code Before I continue, here's something I had to remember: when you're adding console.log statements to library code in node_modules, your logs might not show up because modules get cached. I spent way too long wondering why my logs weren't appearing before I remembered to run: console.log node_modules pnpm start --reset-cache pnpm start --reset-cache Adding logs directly to library code is actually super helpful when you're dealing with weird behavior - you can see exactly what's happening inside the library, trace the execution flow, and peek at internal state that's not exposed through the public API. Just don't forget to clear that cache! Going Back in Time At this point, I was stuck. The code was working before, so what changed? I did what I should have done from the start: I checked the git history. I went through past commits one by one until I found a commit where everything worked. Then I compared the difference between the working state and the broken state. Bingo - there it was, a single line change in .npmrc: .npmrc + node-linker=hoisted + node-linker=hoisted That one line was the culprit. What Actually Happened After adding node-linker=hoisted, pnpm switched to a flat structure similar to npm, and that broke the sharing mechanism by creating separate valtio instances: node-linker=hoisted node_modules/valtio (version 1.13.2)
node_modules/@reown/appkit-core-react-native/node_modules/valtio (version 2.1.8)
node_modules/@reown/appkit-react-native/node_modules/valtio (version 2.1.8) node_modules/valtio (version 1.13.2)
node_modules/@reown/appkit-core-react-native/node_modules/valtio (version 2.1.8)
node_modules/@reown/appkit-react-native/node_modules/valtio (version 2.1.8) Why did this happen? A few reasons: Version mismatch: The root had 1.13.2 (some transitive dependency), while the nested packages needed 2.1.8
No virtual store: With node-linker=hoisted, pnpm doesn't use the .pnpm virtual store structure that ensures proper symlinking
pnpm kept them separate to avoid conflicts Version mismatch: The root had 1.13.2 (some transitive dependency), while the nested packages needed 2.1.8 Version mismatch 1.13.2 2.1.8 No virtual store: With node-linker=hoisted, pnpm doesn't use the .pnpm virtual store structure that ensures proper symlinking No virtual store node-linker=hoisted .pnpm pnpm kept them separate to avoid conflicts Since they were using different valtio instances, and each instance had its own proxyStateMap WeakMap, the proxy object stored in one proxyStateMap wasn't found when subscribe() looked in a different proxyStateMap. proxyStateMap proxyStateMap subscribe() proxyStateMap The Fix The solution was to force all valtio dependencies to use the same version. I added this to my root package.json: package.json {
  "pnpm": {
    "overrides": {
      "valtio": "2.1.8"
    }
  }
} {
  "pnpm": {
    "overrides": {
      "valtio": "2.1.8"
    }
  }
} Then ran pnpm install, and that was it. This: pnpm install Unified all valtio to 2.1.8
Allowed pnpm to hoist it to the root
Removed the nested instances
Made all packages share the same proxyStateMap Unified all valtio to 2.1.8 2.1.8 Allowed pnpm to hoist it to the root Removed the nested instances Made all packages share the same proxyStateMap proxyStateMap Alternatively, I could have just removed node-linker=hoisted to go back to pnpm's default virtual store, which handles this automatically. But I needed the hoisted structure for other reasons, so the override approach worked better for me. node-linker=hoisted Key Takeaways Check git history first - When something breaks, see what changed. The diff often reveals the root cause immediately.
Adding console.log to library code is a good debugging habit - When you encounter weird library behavior, adding logs directly in node_modules can reveal exactly what's happening inside the library. Just remember to use --reset-cache when debugging library code in node_modules to see your changes.
Multiple package instances can break singleton-like behavior - Libraries that rely on WeakMaps, module-level state, or singletons can fail when multiple instances exist. This isn't just a valtio thing - it can happen with any library that maintains internal state.
Version mismatches prevent hoisting - Even with node-linker=hoisted, pnpm will keep separate instances if versions differ. Use pnpm.overrides to force consistent versions across your workspace. Check git history first - When something breaks, see what changed. The diff often reveals the root cause immediately. Check git history first Adding console.log to library code is a good debugging habit - When you encounter weird library behavior, adding logs directly in node_modules can reveal exactly what's happening inside the library. Just remember to use --reset-cache when debugging library code in node_modules to see your changes. Adding console.log to library code is a good debugging habit node_modules --reset-cache node_modules Multiple package instances can break singleton-like behavior - Libraries that rely on WeakMaps, module-level state, or singletons can fail when multiple instances exist. This isn't just a valtio thing - it can happen with any library that maintains internal state. Multiple package instances can break singleton-like behavior Version mismatches prevent hoisting - Even with node-linker=hoisted, pnpm will keep separate instances if versions differ. Use pnpm.overrides to force consistent versions across your workspace. Version mismatches prevent hoisting node-linker=hoisted pnpm.overrides Happy debugging!

This story contains new, firsthand information uncovered by the writer.

How Multiple Valtio Instances Broke My React Native App

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Human Oversight Remains Essential for AI Coders

Using ChatGPT Like a Junior Dev: Productive, But Needs Checking

Why Designers and Developers Must Rethink the Web Interfaces for an AI-First Era

A Lightweight, Open-Source Backend You Can Set Up in Minutes

Code Sharing in Microservice Architecture: Creating Your Own Common Library

Dependency Management in Microservice Architecture: Creating Your Own Parent POM

Human Oversight Remains Essential for AI Coders

Using ChatGPT Like a Junior Dev: Productive, But Needs Checking

Why Designers and Developers Must Rethink the Web Interfaces for an AI-First Era

A Lightweight, Open-Source Backend You Can Set Up in Minutes

Code Sharing in Microservice Architecture: Creating Your Own Common Library

Dependency Management in Microservice Architecture: Creating Your Own Parent POM

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps