@react-aria/i18n@3.13.0 ESM entry fails in Netlify SSR: private useMessageFormatter.js has no named export

[monarcode]

Provide a general summary of the issue here

Summary

After upgrading dependencies, our Netlify SSR function started failing at
runtime when importing @react-aria/i18n@3.13.0.

The package ESM entry dist/import.mjs imports:

import { useMessageFormatter } from "./private/useMessageFormatter.js";

In the Netlify runtime, that private .js file appears to be interpreted in a
way that does not expose the named ESM export, causing the SSR function to
crash.

Error

SyntaxError: The requested module './private/useMessageFormatter.js' does not provide an export named 'useMessageFormatter'

file:///var/task/node_modules/.pnpm/@react-aria+i18n@3.13.0_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/@react-aria/i18n/dist/import.mjs:1
import {useMessageFormatter as ...} from "./private/useMessageFormatter.js";
        ^^^^^^^^^^^^^^^^^^^

Environment

• @react-aria/i18n: 3.13.0
• react: 19.2.4
• react-dom: 19.2.4
• Package manager: pnpm
• Runtime/deploy target: Netlify SSR function
• Node version: 24.14.0
• Bundler/framework: Vite / TanStack Start / Netlify adapter

Local reproduction signal

This reproduces locally when running Node with module syntax detection disabled:

node --no-experimental-detect-module --input-type=module -e "import('@react-aria/i18n')"

Expected behavior

@react-aria/i18n should be importable in Node SSR environments and should
expose useMessageFormatter without relying on runtime-specific interpretation
of private .js files.

Workaround

Bundling the dependency into the SSR output avoids the crash:

// vite.config.ts
export default defineConfig({
	ssr: {
		noExternal: ["@react-aria/i18n"],
	},
});

In our app, this dependency is pulled through @heroui/react@3.0.3, so we also
bundled @heroui/react.

Question

Is @react-aria/i18n@3.13.0 expected to work in Node SSR environments where
package-private .js files are not interpreted as ESM via syntax detection? If
so, could the package publish metadata or file extensions be adjusted so
dist/import.mjs can safely import the private module?

🤔 Expected Behavior?

@react-aria/i18n should be importable in Node SSR environments and should
expose useMessageFormatter without relying on runtime-specific interpretation
of private .js files.

😯 Current Behavior

App breaks on netlify with:

SyntaxError: The requested module './private/useMessageFormatter.js' does not provide an export named 'useMessageFormatter'

file:///var/task/node_modules/.pnpm/@react-aria+i18n@3.13.0_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/@react-aria/i18n/dist/import.mjs:1
import {useMessageFormatter as ...} from "./private/useMessageFormatter.js";
        ^^^^^^^^^^^^^^^^^^^

💁 Possible Solution

Workaround

Bundling the dependency into the SSR output avoids the crash:

// vite.config.ts
export default defineConfig({
	ssr: {
		noExternal: ["@react-aria/i18n"],
	},
});

🔦 Context

I updated my tanstack start app packages to latest versions of Hero ui and React aria

🖥️ Steps to Reproduce

1. Install @react-aria/i18n@3.13.0 in a Node SSR project.

2. Import @react-aria/i18n from an SSR/server entry or from a dependency that
   is externalized by the server bundle.

3. Run the server bundle in a runtime where package-private .js files are not
   interpreted as ESM via syntax detection. For example:

   node --no-experimental-detect-module --input-type=module -e "import('@react-aria/i18n')"

4. Observe the runtime import failure for
   ./private/useMessageFormatter.js.

Version

@react-aria/i18n: 3.13.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[yhatt]

I also encountered the same issue with Next.js SSR function. In that case, a workaround is setting transpilePackages on next.config.js like this:

/** @type {import('next').NextConfig} */
const nextConfig = {
  transpilePackages: ['@react-aria/i18n'],
}
 
module.exports = nextConfig

[devongovett]

FYI this hook has been deprecated since 2022. I would recommend migrating to something else (e.g. using intl-messageformat directly).

We can fix the build issue here though by bringing back the .mjs version. We didn't catch this because Node.js no longer requires it.