Running StyleX babel plugin on node_modules without webpack resolving transitive imports?

[BMCwebdev]

Setup

We have a Next.js app that consumes a shared component library and a design tokens package. Both ship uncompiled StyleX — the packages are built with tsup (TypeScript to JavaScript), but stylex.create() / stylex.props() calls are left in the output for the consumer to compile at build time.

To handle this, we run babel-loader + @stylexjs/babel-plugin on those packages inside node_modules via a custom webpack rule, and use @stylexjs/postcss-plugin for CSS generation:

// next.config.mjs (relevant webpack config only)
webpack: (config, { isServer, dev }) => {
  const stylexConfig = {
    dev,
    runtimeInjection: false,
    genConditionalClasses: true,
    treeshakeCompensation: true,
    aliases: { '@/*': [path.join(import.meta.dirname, '*')] },
    unstable_moduleResolution: { type: 'commonJS' },
  };

  // StyleX compilation for app source files
  config.module.rules.push({
    test: /\.(js|jsx|ts|tsx)$/,
    include: [path.resolve(import.meta.dirname, 'app')],
    use: [{
      loader: 'babel-loader',
      options: {
        cacheDirectory: true,
        parserOpts: { plugins: ['typescript', 'jsx'] },
        plugins: [['@stylexjs/babel-plugin', stylexConfig]],
      },
    }],
  });

  // StyleX compilation for library packages in node_modules
  config.module.rules.push({
    test: /\.(js|jsx|ts|tsx|mjs)$/,
    include: [
      /node_modules[\\\/]@acme[\\\/]design-tokens/,
      /node_modules[\\\/]@acme[\\\/]component-library/,
    ],
    use: [{
      loader: 'babel-loader',
      options: {
        cacheDirectory: true,
        parserOpts: { plugins: ['typescript', 'jsx'] },
        plugins: [['@stylexjs/babel-plugin', stylexConfig]],
      },
    }],
  });

  return config;
},

This works for StyleX compilation. The problem is what it does to webpack's module resolution.

The problem

When the webpack babel rule targets our component library inside node_modules, webpack treats the entire package as source code and follows its full import graph — including into transitive dependencies that have nothing to do with StyleX.

Our component library includes chart components that import from @highcharts/react, which internally imports highcharts/esm/highcharts.src.js. That file is a webpack-prebundled artifact (it contains its own embedded __webpack_require__ runtime). When our app's webpack follows the import chain into that file and tries to re-process it, the two webpack runtimes conflict and the app crashes:

component-library.js
  → @highcharts/react/Highcharts.js
    → highcharts/esm/highcharts.src.js  (webpack-prebundled artifact)
      → consumer's webpack tries to wrap it in its own module system
        → TypeError: undefined is not a non-null object

We only need webpack to run the StyleX babel plugin on our library's files. We don't need it to chase and re-process every transitive dependency the library imports. But the webpack rule's include pattern controls which files the loader runs on — it doesn't prevent webpack from resolving and processing the imports found in those files.

Our workaround

We added a webpack alias to redirect the specific problematic import:

config.resolve.alias['highcharts/esm/highcharts.src.js'] = path.resolve(
  import.meta.dirname,
  'node_modules/highcharts/highcharts.src.js',
);

This redirects from the prebundled ESM artifact to the standard source file (same package, same version, same API — just a different module format wrapper). It works, but it's a per-dependency workaround. If another transitive dependency has a similar packaging issue, we'd need another alias.

The Highcharts packaging issue is tracked upstream at highcharts/highcharts#24243.

The question

Is there a recommended way to run the StyleX babel plugin on packages inside node_modules without causing webpack to deeply resolve their entire transitive import graph?

To be specific about what we need:

• Do resolve: imports between our own packages (the component library imports from the design tokens package — both ship uncompiled StyleX and both need the babel transform)
• Don't resolve: imports into unrelated pre-built dependencies like @highcharts/react, highcharts, or anything else the library depends on that doesn't contain StyleX

Is there a configuration pattern, a webpack feature, or a different integration approach that would give us this kind of scoping? Or is the expectation that consumers running the StyleX babel plugin on node_modules packages will inherently cause webpack to follow the full import graph, and workarounds like ours are the way to handle any conflicts that arise?

[BMCwebdev]

One more thing I wanted to call out, separate from the webpack resolution question above.

Early on, there were Next.js examples that integrated Open Props (@stylexjs/open-props). Those setups were very close to what we're doing now: the design system ships uncompiled StyleX, and the consumer's build has to compile StyleX inside node_modules — not just in app source.

You can still see traces of that in the repo history. For example, PR #781 updated the Next.js example's PostCSS config to include @stylexjs/open-props under node_modules (and even had a follow-up fix for those globs). That was a useful reference for anyone shipping a token/package library the same way.

I completely understand why those examples were trimmed over time — you don't want third-party libraries cluttering the core StyleX docs. But the use case didn't go away. Shipping an uncompiled design system and compiling it in the consuming app is, I think, a common pattern (we're doing it with our own packages; others will do the same).

The problem is that the current Next.js installation guide reads like it covers every Next + StyleX app. In practice it documents app-local StyleX only: babel.config.js, PostCSS include limited to src/ / app/ / components/, no next.config changes. It does not explain that consumers also need:

• PostCSS include paths into node_modules for the design system package(s), and
• Bundler-side @stylexjs/babel-plugin on those packages (babel-loader / turbopack.rules) — transpilePackages alone isn't enough.

That's a different integration than the guide describes, especially with Next.js 16 defaulting to Turbopack and excluding node_modules from Babel unless you opt in explicitly.

It would help a lot if the docs had a dedicated section for this pattern — even a short "Consuming an uncompiled StyleX library" page that points to the extra PostCSS + bundler config, calls out the tradeoffs (double compile, transitive dependency resolution, etc.), and maybe links to this thread. Happy to contribute wording or a doc PR if that's useful.

Thanks again for engaging on this.