[React 19] useSyncExternalStore shim might break about react

[eps1lon]

This is a bug that's caused by our console.error transform. For anybody interested in contributing: We need to use an escape hatch and call console['error']() instead. For testing, you can check the build output in /build after yarn build use-sync-external-store and shouldn't find any mention of __CLIENT_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE

[phryneas]

Easy React PR? Hold my beer :)

[eps1lon]

It's not crashing, right? I think it just misses component stacks which console['error'] would also.

[phryneas]

I'm pretty sure it wouldn't even compile because of the reference, and you've explicitly set that up to fail builds.

But I gotta be honest, I don't have the correct environment set up to actually test that assumption. I was reading the shipped source code when I stumbled upon this.

[eps1lon]

I'm pretty sure it wouldn't even compile because of the reference, and you've explicitly set that up to fail builds.

How did we set it up to fail builds?

[eps1lon]

Just double checked and we do have a test suite that runs against 17. It just doesn't test component stacks for warnings which would be missing when you use use-sync-external-store@rc and React 17.

[eps1lon]

It does crash at runtime when we would trigger warnings. The only case right now is when you'd return an uncached snapshot:

const { text } = useSyncExternalStore(store.subscribe, () => {
  // Intentionally return an uncached snapshot to trigger warnings
  return { ...store.getState() };
});

-- https://codesandbox.io/p/sandbox/react-19-uses-old-react-vl547c

[phryneas]

How did we set it up to fail builds?

From what I gather, by no longer exporting __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED from React , webpack will now crash when a module tries to import that property. I had assumed that was intentional.

At least we had reports of that happening. (As a stopgap, rehackt exports this as undefined if it doesn't exist in the upstream React version, and we're now migrating to a non-internals-accessing workaround)