Bug: highcharts/esm/highcharts.src.js crashes in Next.js/Webpack app, while highcharts/highcharts.src.js works

[BMCwebdev]

Note, originally posted here: #566
But realized perhaps belongs in this repo

Expected behaviour

Importing Highcharts through @highcharts/react (which resolves to highcharts/esm/highcharts.src.js) should work in a Next.js app build/runtime without additional webpack aliasing.

Charts should render normally, and the app should not crash at runtime.

Actual behaviour

The app crashes when the Highcharts ESM path is used:

• problematic path: highcharts/esm/highcharts.src.js
• observed in client bundle/runtime (not an SSR-only failure)
• observed runtime error: TypeError: undefined is not a non-null object (evaluating '__webpack_require__.r(...)')
• crash disappears when aliasing:
  • highcharts/esm/highcharts.src.js -> highcharts/highcharts.src.js

In our consumer app, this alias makes charts render successfully and avoids the runtime crash.

Context

We maintain a component/design-system library that includes chart components and is consumed by multiple downstream apps.
This issue surfaced in one consumer app (Next.js + webpack) through dependency traversal from our shared library into @highcharts/react, even when the consumer app was not actively rendering chart components.

Packaging observation

From our investigation:

• highcharts/esm/highcharts.src.js appears to be a webpack-prebundled artifact (it includes webpack runtime symbols such as __webpack_require__).
• Specifically, the file starts by defining its own webpack runtime scope, including var __webpack_require__ = {};.
• highcharts/highcharts.src.js is packaged as a UMD build.
• In our consumer setup, aliasing the ESM path to the UMD source entry eliminates the crash.

Our current working theory is that this is a bundler compatibility issue with the specific ESM artifact shape in this environment.

Live demo with steps to reproduce

We do not have a public demo URL, but we have a consistent local repro in a Next.js app:

1. Install dependencies and start app normally.
2. Render a page/component that uses chart components from @highcharts/react (in our case via a shared component library).
3. Observe runtime crash when highcharts/esm/highcharts.src.js is in use.
4. Add webpack alias:
   • highcharts/esm/highcharts.src.js -> highcharts/highcharts.src.js
5. Restart app and load the same chart page.
6. Observe successful render and no crash.

Minimal chart usage we validated:

<BarChart
  categories={['Q1', 'Q2', 'Q3', 'Q4']}
  title="Average gift amount"
  xAxisLabel="Quarter"
  yAxisLabel="Amount (USD)"
>
  <BarChartSeries name="Avg. gift" data={[45.5, 62.75, 38.2, 71.33]} />
</BarChart>

Product version

Highcharts Core 12.5.0
@highcharts/react 4.x (resolved in lockfile to 4.2.1)

Affected browser(s)

Reproduced in local development in Chrome (latest).
Given this appears tied to bundling/runtime module resolution, impact may be browser-agnostic once bundle is produced.

Maintainer guidance requested

Could you confirm whether this is a known issue with the
highcharts/esm/highcharts.src.js entry in webpack/Next.js environments?

We currently work around it by aliasing:

highcharts/esm/highcharts.src.js -> highcharts/highcharts.src.js

Is this the recommended approach, or is there a better supported integration path we should adopt?

If our understanding is off, please correct us on the intended packaging/entrypoint usage for component-library producers with downstream consumers.

[KamilKubik]

Hello BMCwebdev and thanks for reaching out!

The integration is ESM first, and it's recommended to import every module accordingly to work properly with bundlers. Therefore, we should aim to make highcharts/esm/highcharts.src.js work properly. It's not a known issue. I tried to reproduce it locally (build/runtime) by creating charts directly, moving them as a separate, bundled package, and in different environments, but so far, I haven’t received the same error.

It would be great if you could share a minimal bundled version of your components, webpack configuration, environment details, or anything that would help reproduce it. If possible, you can use this as a starting point.

Looking forward to your response.

[BMCwebdev]

Thanks for looking into this — appreciate the quick response.

You're right that this isn't a common scenario for most consumers importing Highcharts directly. The trigger is specifically that webpack re-processes highcharts/esm/highcharts.src.js — not just imports it, but runs a loader over it and re-wraps it in the consumer's module system.

In our case, we're a component library that ships uncompiled StyleX (Meta's CSS-in-JS framework). Our consumers must run the StyleX Babel plugin over our package at build time, which means adding a babel-loader rule targeting our library inside node_modules. When webpack applies that rule, it follows our full import graph — including into @highcharts/react, which resolves to highcharts/esm/highcharts.src.js. Webpack then re-processes that file, and the embedded webpack_require runtime inside it conflicts with the consumer's webpack runtime.

While our specific case involves StyleX, there are other scenarios where webpack re-processes node_modules files:

• Any CSS-in-JS library that compiles at consumer build time (StyleX, Linaria, vanilla-extract in some configs)
• Monorepo setups where internal packages aren't pre-built and webpack processes them as source
• Custom Babel transforms applied to node_modules (e.g., for polyfilling, instrumentation, or code coverage)
• Micro-frontend architectures where shared dependencies get re-bundled by each app's webpack

The common thread is: if highcharts/esm/highcharts.src.js gets fed through a second webpack pass, the embedded webpack_require conflicts. A clean ESM file (standard import/export, no bundler runtime) would survive re-processing without issue.

If it's helpful, I can try to put together a minimal repro — the simplest version would be a small library that imports @highcharts/react, consumed by a Next.js app with a babel-loader rule targeting that library in node_modules. Happy to use the starter you linked as a base.

[KamilKubik]

Thanks for sharing the details.

Here's a minimal reproduced version. I think the cleanest approach would be to go with either UMD or clear ESM (it's available under /es-modules/masters).

To clarify, changing the alias for the main Highcharts import is not sufficient, as all additional modules must be imported using the same alias, which won't happen automatically for built-in components (assuming you need additional modules). Consequently, you would need to handle all module imports manually. However, I assume that requiring the end user to adjust aliases is not the way to go.

I'll raise this internally to discuss adding UMD format support within the integration, and will get back to you once it's resolved. As a temporary workaround, I successfully bundled highcharts, @highcharts/react, and the custom package together using tsup. I'm aware it increases the package's bundle size, but it also bypasses Webpack. Please see the demo. Let me know if you find it helpful.

[BMCwebdev]

Thanks Kamil — appreciate you reproducing this and raising it internally.

Regarding the tsup workaround — unfortunately that won't work for our setup. Our library ships unbundled source code because we use Meta's StyleX, which requires a Babel transform to run over the original source at consumer build time. So we can't pre-bundle our library's dependencies — the consumer's bundler will always traverse our full import graph, including into @highcharts/react.

Happy to test a pre-release whenever something is ready. Thanks again for looking into this.

[SamHerbert]

Thank you Kamil, the UDM format support will also help us with this issue