[BUG] React runtime resolution issue caused by outdated hardcoded jsx-runtime path

[bufan-huang]

Describe the bug.

React runtime resolution issue caused by outdated hardcoded jsx-runtime path

Problem

The current React version used in generator-react-sdk is outdated and is no longer aligned with other dependent AsyncAPI libraries such as @asyncapi/html-template.

The code currently hardcodes an internal React runtime path:

'react/jsx-runtime': require.resolve(
  'react/cjs/react-jsx-runtime.production.min'
).replace(/\\/g, '/'),

However, this internal path is no longer exposed through React package exports in newer React versions.

This causes runtime resolution failures such as:

Error: Package subpath './cjs/react-jsx-runtime.production.min'
is not defined by "exports"

Example stack trace references packages like:

node_modules/.pnpm/@asyncapi/html-...

Suggested discussion points

• Should AsyncAPI packages align on a consistent React version strategy?
• Should the implementation switch to the public runtime entrypoint instead?

Example:

require.resolve('react/jsx-runtime')

• Is backward compatibility with older React versions still required?

I wanted to open this issue first to discuss the preferred direction with maintainers before continuing with a PR implementation.

Expected behavior

running

Screenshots

Error: Package subpath './cjs/react-jsx-runtime.production.min' is not defined by "exports" in node_modules.pnpm@asyncapi+html-template@3.5_38169f94417d5abe6c7e65de49492da1\node_modules\react\package.json at exportsNotFound (node:internal/modules/esm/resolve:313:10)

dependencies:
nestjs-asyncapi 2.0.1
├─┬ @asyncapi/generator 2.11.0
│ ├─┬ @asyncapi/generator-components 0.6.0
│ │ └─┬ @asyncapi/generator-react-sdk 0.2.25
│ │ └── react 17.0.2
│ └─┬ @asyncapi/generator-react-sdk 0.2.25
│ └── react 17.0.2
└─┬ @asyncapi/html-template 3.5.6
├─┬ @asyncapi/generator-react-sdk 1.1.3
│ └── react 17.0.2
├─┬ @asyncapi/react-component 3.1.3
│ ├── react 18.3.1 peer
│ ├─┬ react-dom 18.3.1 peer
│ │ └── react 18.3.1 peer
│ ├─┬ react-error-boundary 4.1.2
│ │ └── react 18.3.1 peer
│ └─┬ use-resize-observer 9.1.0
│ ├── react 18.3.1 peer
│ └─┬ react-dom 18.3.1 peer
│ └── react 18.3.1 peer
├── react 18.3.1
└─┬ react-dom 18.3.1
└── react 18.3.1 peer

How to Reproduce

1. I first did this
2. I then did this
3. And so on . . .

🖥️ Device Information [optional]

• Operating System (OS):win 11 pnpm10
• Browser:
• Browser Version:

👀 Have you checked for similar open issues?

• I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue ?

Yes I am willing to submit a PR!

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[bufan-huang]

@https://github.com/asyncapi/generator/pull/2080

[Adi-204]

Investigation reproduced end-to-end during template generation

Did a deep dive on this. The bug is real, the root cause is well-defined, and the fix the original reporter proposes is correct. Posting the full reproduction here so it's actionable.

Root cause

One line in apps/react-sdk/src/transpiler/transpiler.ts:

paths: {
  'react/jsx-runtime': require.resolve('react/cjs/react-jsx-runtime.production.min').replace(/\\/g, '/'),
}

react/cjs/react-jsx-runtime.production.min is a private internal of React. It happens to be reachable on React 17 because React 17 has no exports field — but React 18+ added a restricted exports map that only exposes the public entry points.

Quick proof straight from the registry:

$ npm view react@18.3.1 exports
{
  '.': { default: './index.js', 'react-server': './react.shared-subset.js' },
  './jsx-runtime': './jsx-runtime.js',
  './package.json': './package.json',
  './jsx-dev-runtime': './jsx-dev-runtime.js'
}

No ./cjs/... in the map → any subpath that isn't listed throws ERR_PACKAGE_PATH_NOT_EXPORTED. React 19 has the same restriction.

End-to-end reproduction (template generation actually fails)

Minimal recipe — fresh directory, three files, then npm install && node run-generator.js:

package.json

{
  "name": "repro-2090",
  "private": true,
  "dependencies": {
    "@asyncapi/generator": "2.11.0",
    "@asyncapi/html-template": "3.5.6",
    "@asyncapi/parser": "^3.0.0"
  },
  "overrides": {
    "react": "18.3.1"
  }
}

asyncapi.yaml

asyncapi: 3.0.0
info: { title: Demo, version: 1.0.0 }
channels:
  ping:
    address: ping
    messages:
      pingMsg: { payload: { type: object } }
operations:
  publishPing:
    action: send
    channel: { $ref: '#/channels/ping' }

run-generator.js

const Generator = require('@asyncapi/generator');
const path = require('path');

(async () => {
  const gen = new Generator(
    '@asyncapi/html-template',
    path.resolve(__dirname, 'output'),
    { forceWrite: true, debug: true }
  );
  try {
    await gen.generateFromFile(path.resolve(__dirname, 'asyncapi.yaml'));
    console.log('SUCCESS');
  } catch (e) {
    console.log('FAILED', e.code);
    console.log(e.message);
    console.log(e.stack.split('\n').slice(0, 10).join('\n'));
  }
})();

npm ls react after install confirms the SDK now sees React 18:

└─┬ @asyncapi/generator@2.11.0
  └─┬ @asyncapi/generator-react-sdk@1.1.3
    └── react@18.3.1 deduped       ← would normally be 17.0.2

Running node run-generator.js produces (byte-for-byte the same error class as the OP, including the exact exportsNotFound frame on internal/modules/esm/resolve:313:10):

Transpilation of files ...\@asyncapi\html-template\template into ...\__transpiled started.
FAILED ERR_PACKAGE_PATH_NOT_EXPORTED
Package subpath './cjs/react-jsx-runtime.production.min' is not defined by "exports" in
  ...\node_modules\react\package.json
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]
    at exportsNotFound          (node:internal/modules/esm/resolve:313:10)
    at packageExportsResolve    (node:internal/modules/esm/resolve:661:9)
    at resolveExports           (node:internal/modules/cjs/loader:679:36)
    at Module._findPath         (node:internal/modules/cjs/loader:746:31)
    at Module._resolveFilename  (node:internal/modules/cjs/loader:1406:27)
    at require.resolve          (node:internal/modules/helpers:163:19)
    at Object.<anonymous>       (...\@asyncapi\generator-react-sdk\lib\transpiler\transpiler.js:93:62)

Generator crashes before writing any file.

Why it doesn't always trigger (matters for "I can't reproduce")

The SDK declares react: ^17.0.1 as a hard dep, so package managers usually protect against this by nesting React 17 next to the SDK. The resolver then finds React 17 first and the bug stays latent. I tried six configurations on Win11 + Node 24 + npm 11 / pnpm 10:

#	Configuration	SDK saw which React?	Generator outcome
1	Plain npm install	nested 17	✅ succeeded
2	Plain pnpm install	.pnpm/react@17.0.2/... (17)	✅ succeeded
3	pnpm + node-linker=hoisted	nested 17	✅ succeeded
4	pnpm + shamefully-hoist=true	still 17 via .pnpm/.../react@17.0.2/...	✅ succeeded
5	pnpm + pnpm.overrides.react=18.3.1	18	❌ ERR_PACKAGE_PATH_NOT_EXPORTED
6	npm + overrides.react=18.3.1	18 (deduped)	❌ ERR_PACKAGE_PATH_NOT_EXPORTED (the minimal recipe above)

The trigger is any package-manager configuration that displaces the SDK's nested React 17 with React 18. The OP's nestjs-asyncapi tree shows React 18 hoisted via html-template + react-component peer chain in pnpm 10 — equivalent mechanism to the overrides repro, just driven by peer-deps virtualization rather than an explicit overrides field.

There's also a secondary issue even when transpilation does succeed today: rollup's paths option bakes an absolute filesystem path into the emitted bundle, e.g.

var jsxRuntime = require('C:/Temp/repro-2090/node_modules/@asyncapi/generator-react-sdk/node_modules/react/cjs/react-jsx-runtime.production.min.js');

So even on installs where the resolution succeeds, the output bundle breaks the moment the project is moved, shipped in a Docker layer, or reinstalled with a different package manager layout. The same hardcoded path also lives in committed snapshots (apps/react-sdk/src/transpiler/__tests__/__snapshots__/transpiler.spec.tsx.snap).

[Adi-204]

@bufan-huang can you provide some more context about project environment and config you are using because for me it was working fine unless you are trying to force react version > 17 by using something like overrides or something else.

[bufan-huang]

@bufan-huang can you provide some more context about project environment and config you are using because for me it was working fine unless you are trying to force react version > 17 by using something like overrides or something else.

use nestjs-asyncapi ，lite bug
https://github.com/bufan-huang/repro-2090

pnpm why react
[WARN] The "pnpm" field in package.json is no longer read by pnpm. The following keys were ignored: "pnpm.onlyBuiltDependencies". See https://pnpm.io/settings for the new home of each setting.
react@17.0.2
└─┬ @asyncapi/generator-react-sdk@1.1.3
├─┬ @asyncapi/generator@2.11.0
│ └─┬ nestjs-asyncapi@2.0.1
│ └── nest-typescript-starter@1.0.0 (dependencies)
├─┬ @asyncapi/generator-components@0.6.0
│ └── @asyncapi/generator@2.11.0 [deduped]
└─┬ @asyncapi/html-template@3.5.6
└── nestjs-asyncapi@2.0.1 [deduped]

react@18.3.1
├─┬ @asyncapi/html-template@3.5.6
│ └─┬ nestjs-asyncapi@2.0.1
│ └── nest-typescript-starter@1.0.0 (dependencies)
├─┬ @asyncapi/react-component@3.1.3
│ └── @asyncapi/html-template@3.5.6 [deduped]
├─┬ react-dom@18.3.1
│ ├── @asyncapi/html-template@3.5.6 [deduped]
│ ├── @asyncapi/react-component@3.1.3 [deduped]
│ └─┬ use-resize-observer@9.1.0
│ └── @asyncapi/react-component@3.1.3 [deduped]
├─┬ react-error-boundary@4.1.2
│ └── @asyncapi/react-component@3.1.3 [deduped]
└── use-resize-observer@9.1.0 [deduped]

Found 2 versions of react

$ nest start
node:internal/modules/cjs/loader:692
throw e;
^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/utils/validate-path.util' is not defined by "exports" in /Users/hby/Desktop/hby/project/github/repro-2090/node_modules/.pnpm/nestjs-asyncapi@2.0.1_@nestjs+common@11.1.26_reflect-metadata@0.2.2_rxjs@7.8.2__@nestjs_f033254d030d9210da42bf786e60bdd5/node_modules/@nestjs/swagger/package.json
at exportsNotFound (node:internal/modules/esm/resolve:310:10)
at packageExportsResolve (node:internal/modules/esm/resolve:658:9)
at resolveExports (node:internal/modules/cjs/loader:685:36)
at Module._findPath (node:internal/modules/cjs/loader:752:31)
at Module._resolveFilename (node:internal/modules/cjs/loader:1461:27)
at wrapResolveFilename (node:internal/modules/cjs/loader:1049:27)
at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1073:10)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1094:12)
at Module._load (node:internal/modules/cjs/loader:1262:25)
at wrapModuleLoad (node:internal/modules/cjs/loader:255:19) {
code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Node.js v24.15.0
[ELIFECYCLE] Command failed with exit code 1.

[Adi-204]

@bufan-huang thanks for the repro and the pnpm why react output, but I think the error you just pasted is a different problem.

The traceback you posted is:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/utils/validate-path.util'
is not defined by "exports" in .../node_modules/.pnpm/nestjs-asyncapi@2.0.1.../@nestjs/swagger/package.json

That is nestjs-asyncapi@2.0.1 reaching into a private internal of @nestjs/swagger (dist/utils/validate-path.util). A recent @nestjs/swagger release made that file private via its exports map, so Node blocks the import and nest start crashes. That's a nestjs-asyncapi / @nestjs/swagger version-compat issue in your app's startup path — it has nothing to do with the generator's React transpiler, and the crash happens during nest start, not during template generation.

The React ERR_PACKAGE_PATH_NOT_EXPORTED in #2090 is specifically about react/cjs/react-jsx-runtime.production.min inside @asyncapi/generator-react-sdk's transpiler. Your pnpm why react actually shows that side is fine:

react@17.0.2
└─┬ @asyncapi/generator-react-sdk@1.1.3

The SDK resolves its nested react@17.0.2, which is exactly the working case — React 17 has no exports restriction, so the react/cjs/... subpath resolves and transpilation succeeds. The react@18.3.1 in your tree is isolated to the @asyncapi/html-template / @asyncapi/react-component / react-dom runtime peer chain; it never displaces the SDK's React 17, so the #2090 transpiler crash won't fire here.