commonjs - Missing export (Error: ... is not exported by ...)

@lukastaegert

Rollup Plugin Name: commonjs
Rollup Plugin Version: 20.0.0
Rollup Version: 2.56.3
Operating System (or Browser): macOS
Node Version: 16
Link to reproduction (⚠️ read below): https://replit.com/@danielcgindi/rollup-plugin-repro-4

Expected Behavior

Should correctly export whatever is imported.

Actual Behavior

Weird and irrelevant export.

The piece of code (importDeclaration.module.info.code) that fails looks like this:

import * as commonjsHelpers from "�commonjsHelpers.js";
import { __exports as mongodb } from "\u0000/Users/user/git/server/node_modules/mongodb/index.js?commonjs-exports"

export default commonjsHelpers.commonjsRequire("/$$rollup_base$$/node_modules/mongodb/index.js", "/$$rollup_base$$/node_modules/mongodb");

@lukastaegert this looks like it's originating from the latest refactor during the circular dependencies support. While mongodb cannot be rolled up normally as it has severe circular dependencies, it seems to not be able to be rolled up dynamically too due to this bug. It looks like this should have been a reexport of __exports or at least *.
I tried to look into this and have not found what causes this to compose in such a way.
It's probably line 228 in index.js, but how do we make it play well with the other stuff that's being shoved in there?

Seems to be resolved by #1038

There still seems to be the or at least a bug.

In Short: I am importing a lib that depends on axios/axios.

After updating to a version > 18 the import failed with

The requested module ... does not provide an export named 'exports'

as mentioned here and in the related post here: #modernweb-dev/web#1700.

Following the discussion(s) in #1038 and updating to v20.0.4 (beta), I get the following (new) error, though:

Error while transforming ... Could not resolve import "commonjsHelpers.js"

1 | import * as commonjsHelpers from "commonjsHelpers.js";
2 | import require$$0 from...

@phihu

I'm in the same boat as @phihu - any advice or direction here would be much appreciated :)

Anyone any success?
Problem still exists, even using the latest (beta) release v22.0.0-13

v22.0.0 release and problem still exists

try transforming to commonjs the deepmerge npm module

I also am getting the same kind of error message with version 22.0.0 when trying to process @testing-library/dom:

Error while transforming node_modules/@testing-library/dom/dist/helpers.js: Could not resolve import "commonjsHelpers.js".
> 1 | import * as commonjsHelpers from "commonjsHelpers.js";
    |                                  ^
  2 | import { __exports as helpers } from "\u0000/[redacted]/node_modules/@testing-library/dom/dist/helpers.js?commonjs-exports"
  3 |
  4 | "use strict";

For anyone stuck at this problem: downgrading @rollup/plugin-commonjs to v21 solves for me.

I'm having the same issue using vitejs when importing photoswipe.

If anyone finds any additional solutions, please update the thread! I'm also facing the same issue and downgrading hasn't helped either.

Also having issues with this. Using via web-test-runner. Downgrading to v21 just freezes web-test-runner, while latest release errors with Could not resolve import "commonjsHelpers.js".

Same issue here with vitejs :
I tried with @rollup/plugin-commonjs@20, @rollup/plugin-commonjs@21, @rollup/plugin-commonjs@latest (23) with the same result..

Error when using sourcemap for reporting an error: Can't resolve original location of error.
'getDefaultExportFromCjs' is not exported by 'commonjsHelpers.js'
'commonjsGlobal' is not exported by 'commonjsHelpers.js'
(...)
'commonjsGlobal' is not exported by 'commonjsHelpers.js'
Error when using sourcemap for reporting an error: Can't resolve original location of error.
'getDefaultExportFromCjs' is not exported by 'commonjsHelpers.js'
'commonjsGlobal' is not exported by 'commonjsHelpers.js'
✓ 3521 modules transformed.
'getAugmentedNamespace' is not exported by commonjsHelpers.js, imported by __vite-browser-external?commonjs-proxy
file: __vite-browser-external?commonjs-proxy:1:75
1: import * as __viteBrowserExternal from "__vite-browser-external"; import { getAugmentedNamespace } from "commonjsHelpers.js"; export default /*@__PURE__*/getAugmentedNamespace(__viteBrowserExternal);
                                                                              ^
error during build:
Error: 'getAugmentedNamespace' is not exported by commonjsHelpers.js, imported by __vite-browser-external?commonjs-proxy

Any updates on this issue? v24.0.0 and still has issue.

Same issue still with v24.0.1
Could not resolve import "commonjsHelpers.js"

Is this being addressed?

I just tried this setting out and confirmed that it is still happening. I am not using Vite, but I am am using Web Dev Server <https://modern-web.dev/docs/dev-server/overview/> with Storybook, so I am setting strict-requires on the plugin through that config. The issue seems to be that I am using an ES Module ***@***.***/client-api) which imports a commonjs library. The imports are for "global/window.js", "core-js/ and "qs". Everything works fine when I have commonjs plugin active and I don't import the library I am having issues with.

…

On Fri, Feb 3, 2023 at 12:41 AM Lukas Taegert-Atkinson < ***@***.***> wrote: Did you try build: { commonjsOptions: { strictRequires: true } } in your Vite config? — Reply to this email directly, view it on GitHub <#986 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFXK7EC6RL5O7CLBY6TLDWVTAC5ANCNFSM5DHI7CGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

I also have this issue using vite --version: vite/4.1.4 darwin-x64 node-v18.14.0
vite dev server works. When i try to build i get RollupError:

"getAugmentedNamespace" is not exported by "commonjsHelpers.js", imported by "/opt/app/node_modules/react-use/esm/index.js?commonjs-proxy".
file: /opt/app/node_modules/react-use/esm/index.js?commonjs-proxy:1:9
1: import { getAugmentedNamespace } from "commonjsHelpers.js"; import * as esm from "/opt/app/node_modules/react-use/esm/index.js"; export default /*@__PURE__*/getAugmentedNamespace(esm);

When i add react-use to commonjsOptions.ignore, the error jumps to the next lib:

"getAugmentedNamespace" is not exported by "commonjsHelpers.js", imported by "/opt/app/node_modules/react-popper/lib/esm/index.js?commonjs-proxy".
file: /opt/app/node_modules/react-popper/lib/esm/index.js?commonjs-proxy:1:9
1: import { getAugmentedNamespace } from "commonjsHelpers.js"; import * as esm from "/opt/app/node_modules/react-popper/lib/esm/index.js"; export default /*@__PURE__*/getAugmentedNamespace(esm);

What am i missing? Any hints on investigating this?

I am using Rollup to create an npm pacakge and I have the following versions:

"rollup": "^3.29.4",
"@rollup/plugin-commonjs": "^25.0.7",

I can see in the bundle file that the plugin adds the line import * as commonjsHelpers from 'commonjsHelpers.js';. However, when I install the package on another project I get the above errors. Inspecting what is actually in the npm package, I cannot find the file "commonjsHelpers.js". Could it be a misconfiguration of the plugin?

A simplified rollup.config.ts version:

// omitting imports to save space

const rollupConfiguration = [
	{
		input: ['./src/index.tsx'],
		external: [...Object.keys(pkg.peerDependencies || {}), /@babel\/runtime/],
		output: [
			{
				file: pkg.main,
				format: 'cjs',
				sourcemap: !production,
			},
			{
				file: pkg.module,
				format: 'es',
				exports: 'named',
				sourcemap: !production,
			},
		],
		plugins: [
			nodeResolve(),
			commonjs({
				sourceMap: !production,				
			}),
			babel({
				exclude: 'node_modules/**',
				presets: ['@babel/preset-react', ['@babel/preset-env']],
				babelrc: false,
				babelHelpers: 'runtime',
				plugins: ['@babel/plugin-transform-runtime'],
			}),
			postcss({
				extract: true,
				modules: false,
				use: ['sass'],
			}),
			typescript({
				sourceMap: !production,
				inlineSources: !production,
				target: 'es6',
			}),
			production && terser(),
		],
	},
];

export default rollupConfiguration;

rollup 3.29.4
@rollup/plugin-commonjs 25.0.7

Trying out and adding some babel/rollup plugins:

pnpm dlx create-remix@latest --template remix-run/remix/templates/unstable-vite-express

I also got that kind of error:

"getAugmentedNamespace" is not exported by "commonjsHelpers.js", imported by "remix-vite-experimental/node_modules/.pnpm/core-js@3.33.2/node_modules/core-js/internals/fails.js?commonjs-proxy".

Beginning of stack:

error during build:
RollupError: "getAugmentedNamespace" is not exported by "commonjsHelpers.js", imported by "/Users/RomuQuan/Documents/devserver/workspace/remix-vite-experimental/node_modules/.pnpm/core-js@3.33.2/node_modules/core-js/internals/fails.js?commonjs-proxy".
    at error (remix-vite-experimental/node_modules/.pnpm/rollup@3.29.4/node_modules/rollup/dist/es/shared/node-entry.js:2287:30)
    at Module.error (remix-vite-experimental/node_modules/.pnpm/rollup@3.29.4/node_modules/rollup/dist/es/shared/node-entry.js:13745:16)
    at Module.traceVariable (remix-vite-experimental/node_modules/.pnpm/rollup@3.29.4/node_modules/rollup/dist/es/shared/node-entry.js:14175:29)
    at ModuleScope.findVariable (remix-vite-experimental/node_modules/.pnpm/rollup@3.29.4/node_modules/rollup/dist/es/shared/node-entry.js:12615:39)
    at Identifier.bind (remix-vite-experimental/node_modules/.pnpm/rollup@3.29.4/node_modules/rollup/dist/es/shared/node-entry.js:8319:40)

import { unstable_vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths";
import babel from 'vite-plugin-babel';
import commonjs from '@rollup/plugin-commonjs';
import { nodeResolve } from '@rollup/plugin-node-resolve';

export default defineConfig({
  plugins: [
    nodeResolve(),
    commonjs(),
    babel(),
    remix(),
    tsconfigPaths()
  ],
});

@cr4dle

@cr4dle I also can't find the file commonjsHelpers.js

how to resolve it ?

any update?

Dang, three years and this still exists. This unfortunately makes Vite completely unusable for us as it causes builds to fail, and we don't have control over the rollup plugin version Vite uses under the hood.

@CharlieHelps

@CharlieHelps please read through the issue, follow links, and consider the source code on master branch and triage the issue

Expand this to see my work.

Read the new comment and mapped the ask to triage behavior in @rollup/plugin-commonjs against current master sources.
Searched packages/commonjs for commonjsHelpers and found only two source hits—packages/commonjs/src/helpers.js:21 defining HELPERS_ID = '\0commonjsHelpers.js' and packages/commonjs/src/transform-commonjs.js:430 assigning helpersName = deconflict(..., 'commonjsHelpers')—with remaining matches limited to tests (helpers.js, transform-commonjs.js).
Reviewed packages/commonjs/src/helpers.js and confirmed getHelpersModule() returns the HELPERS module string exporting commonjsGlobal, getDefaultExportFromCjs, getDefaultExportFromNamespaceIfPresent, getDefaultExportFromNamespaceIfNotNamed, and getAugmentedNamespace.
Narrowed the triage scope to helper import/wrapping via HELPERS_ID and deconflicted alias helpersName, plus related suffix constants (PROXY_SUFFIX, WRAPPED_SUFFIX, ENTRY_SUFFIX, etc.), with no cross-package usages observed in the repo search.
Reviewed packages/commonjs/src/resolve-id.js and confirmed getResolveId() short-circuits helper resolution (importee.startsWith(HELPERS_ID) returns the id), unwraps WRAPPED_SUFFIX, and special-cases MODULE_SUFFIX, EXPORTS_SUFFIX, PROXY_SUFFIX, ES_IMPORT_SUFFIX, and EXTERNAL_SUFFIX, aligning helper/proxy flow with CJS wrapping (resolve-id.js).
Validated expectations via tests showing trackedTransforms include '\0commonjsHelpers.js' alongside proxy/import ids when a dep flips to CJS, e.g. the "handles when an imported dependency of an ES module changes type" case (expected ['dep.js','main.js','\0dep.js?commonjs-es-import','\0commonjsHelpers.js','\0dep.js?commonjs-exports']) (test.js).
Noted additional guards: resolveExtensions() only applies to relative ESM imports and virtual ids starting with '\0' are skipped from further resolution, with currentlyResolving preventing re-entrant resolution loops, matching the test expectations.

Thanks for the ping. I read the full thread, followed the links, and reviewed the current code on master (commit 8851ea4 from Oct 20, 2025). Here’s the triage.

Summary

On master, the CommonJS plugin never emits a bare import of commonjsHelpers.js. It always imports a virtual module id starting with a null prefix: \0commonjsHelpers.js, and it provides that module via load(). See helpers id, exports, and load/import points:
- HELPERS_ID definition: packages/commonjs/src/helpers.js#L21 (commit 8851ea4)
- The helpers module exports commonjsGlobal, getDefaultExportFromCjs, getDefaultExportFromNamespaceIfPresent, getDefaultExportFromNamespaceIfNotNamed, getAugmentedNamespace: packages/commonjs/src/helpers.js#L29-L60 (commit 8851ea4)
- load() serving the helpers module: packages/commonjs/src/index.js#L244-L248 (commit 8851ea4)
- Transform always injects import * as from "\0commonjsHelpers.js": packages/commonjs/src/generate-imports.js#L101-L107 (commit 8851ea4)
The test suite tracks transforms that touch the helpers module and shows the virtual id usage (for example, trackedTransforms includes '\0commonjsHelpers.js'): packages/commonjs/test/test.js#L894-L900 (commit 8851ea4).

What the reported errors imply

Messages like:
- Could not resolve import "commonjsHelpers.js"
- 'getAugmentedNamespace' is not exported by "commonjsHelpers.js"
  typically mean something upstream/downstream is rewriting or stripping the \0 prefix from the virtual id (turning it into a bare commonjsHelpers.js) or resolving it to a different helpers file that doesn’t export those names.
This matches reports in this thread from Vite, Web Dev Server, and Web Test Runner. Those tools inject their own CommonJS proxies/helpers in some modes. The error shapes shown (bare commonjsHelpers.js without the underscore Rollup often adds when emitting a helpers chunk) point to integration layers rather than the plugin’s current logic.
A separate, common cause (reported above by library authors) is publishing a multi‑chunk build but omitting the emitted helpers chunk from the package. If your published ESM/CJS refers to a helpers chunk (often named _commonjsHelpers.js), that file must be shipped with the package.

Status on master (as of Oct 20, 2025)

The helpers module is a virtual module served by the plugin and exports the symbols users report missing.
Recent fixes in commonjs (e.g., strict require semantics, dynamic require handling, builtins handling) are in place; I don’t see code paths that would emit a literal "commonjsHelpers.js" import.

Next steps to move this forward

Narrow the scope to the plugin itself
- Please provide a fresh minimal reproduction that uses Rollup directly (no Vite/WDS/WTR), Rollup v4.x, and @rollup/plugin-commonjs v28.0.8 (or master). Include:
  - rollup.config.js with nodeResolve() then commonjs({ strictRequires: 'auto' (default) })
  - Exact Rollup and Node versions
  - A single entry that triggers the failure
- If the failure only appears through Vite/WDS/WTR, let’s open an issue on that tool with a link back here; I’ll help cross‑reference.
If you’re publishing a library and seeing these errors in a consuming app
- Ensure the emitted helpers chunk is included in the published files (e.g., your package.json "files" whitelist should include all of dist/**, or don’t prune helper chunks).
- Alternatively, configure Rollup to bundle to a single file per format so no helper chunk is externalized.
For the original mongodb/circular case
- Please retest on the latest plugin. The strictRequires work that landed via feat(commonjs): support strict require semantics for circular imports #1038 (and subsequent fixes) changes how cycles are handled. If there’s still a plugin‑only failure, a minimal Rollup repro will make it actionable.

Proposal for this issue

This thread has accumulated multiple, different scenarios. I suggest we keep commonjs - Missing export (Error: ... is not exported by ...) #986 focused on a plugin‑only repro against current versions. If no current repro can be produced, we can close as effectively resolved; any remaining integration‑specific problems should live in the respective tool’s tracker (with us looped in).

Happy to iterate once there’s a fresh, minimal Rollup repro.

Navigation Menu

Repository navigation

commonjs - Missing export (Error: ... is not exported by ...) #986

Expected Behavior

Actual Behavior

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

commonjs - Missing export (Error: ... is not exported by ...) #986

Description

Expected Behavior

Actual Behavior

Activity

lukastaegert commented on Nov 26, 2021

phihu commented on Jan 11, 2022

emensch commented on Feb 8, 2022

phihu commented on Mar 3, 2022

mihaisavezi commented on Apr 27, 2022

b-houghton commented on Jun 6, 2022

songkeys commented on Jun 14, 2022

jimblue commented on Jul 18, 2022

Ssis53 commented on Aug 22, 2022

mhogara commented on Aug 25, 2022

enjikaka commented on Aug 31, 2022

2 remaining items

zipang commented on Nov 4, 2022

pdmshrestha commented on Jan 2, 2023

vtron commented on Feb 2, 2023

vtron commented on Feb 6, 2023

igl commented on Mar 15, 2023

cr4dle commented on Oct 25, 2023

soundstep commented on Nov 16, 2023

soundstep commented on Nov 16, 2023

kkkkkcnm commented on Feb 4, 2024

niyuanfa commented on Apr 26, 2024

arioooooo commented on Oct 30, 2024

solastley commented on Jan 24, 2025

shellscape commented on Oct 20, 2025

charliecreates commented on Oct 20, 2025

charliecreates commented on Oct 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions