Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fixes #305... again again. The `esm` wrapper (as described in bufbuild/protobuf-es#509) creates problems when using a peer dependency that defines it's exports without an import proxy (in our case, react-query). # Current situation Our exports look like: ```json { "exports": { ".": { "node": { "import": "./dist/proxy/index.js", "require": "./dist/cjs/index.js" }, "module": "./dist/esm/index.js", "import": "./dist/proxy/index.js", "require": "./dist/cjs/index.js" } } } ``` The above meant the following: - When the **application** imported `QueryClientProvider` from `@tanstack/react-query`, it resolved to the `esm` version of the context - When the **library** imported `useQuery` from `@tanstack/react-query`, it resolved instead to the `cjs` version of the package (since NextJS SSR is considered a "node" environment) This mismatch between the esm and cjs versions causes a problem detecting context # Alternatives considered We could expose our own hooks/components with a one-to-one mapping from `@tanstack/react-query` and require our own `QueryClientProvider` to be initialized. This would bypass these kinds of issues, but introduce more setup and potential for confusion. It would mean that using `react-query` for anything non-connect related would require an additional query client provider which MAY actually be the same client depending on where (node/browser) it's running. # Reason we chose this solution By not using an `ESM` wrapper, we avoid these possible import mismatches. It does introduce the possibility of dual package hazard with class instances (where instanceof is used, like with ConnectError) but we don't use any of that in connect-query so we can be relatively safe in that regard.
- Loading branch information