Duplicate atom instances created when using mixed absolute/relative import paths after React 18/Next.js 13 upgrade #3113
Unanswered
usernamechiho
asked this question in
Bug report
Replies: 1 comment
-
I hope someone who is familiar with Next.js 13 can help on it. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Environment
Jotai: ^2.2.3
React: ^18.2.0
Next.js: ^13.5.11
Repo Setup: This issue was observed in a single repository within a larger monorepo structure.
Overview
We've encountered a critical issue with Jotai after upgrading our environment from React 17 and Next.js 12 to React 18 (^18.2.0) and Next.js 13 (^13.5.11). When we import the same atom using both absolute and relative paths in different parts of our application, it appears to create duplicate, independent instances of that atom. This prevents components from subscribing to and updating the correct atom state.
Our application does not use a Jotai
<Provider>
and a store.Current Behavior
When an atom is imported via an absolute path in one file (e.g., import { myAtom } from '~/atoms/myAtom') and via a relative path in another (e.g., import { myAtom } from '../atoms/myAtom'), the two imports resolve to different atom instances. As a result, updates to myAtom in one part of the app are not reflected in components that imported it using the other path.
This behavior is not always consistent but seems to happen intermittently, likely due to how our bundler (part of Next.js) resolves these modules, leading to different references for the same atom.
Expected Behavior
Regardless of whether an atom is imported using an absolute or a relative path, it should always resolve to the same singleton instance. All components referencing that atom should share the same state and receive updates correctly.
Screenshot
Currently
We have attempted to upgrade app versions, but the issue persists. The most likely cause appears to be a module resolution or bundling conflict specific to the new Next.js and React versions. A temporary workaround is to enforce a strict import path policy (e.g., only absolute paths), but this can be difficult to manage across a large codebase.
Beta Was this translation helpful? Give feedback.
All reactions