parcel-bundler/parcel · error · Error

"${src}" does not export "${exportName}".

Error message

"${src}" does not export "${exportName}".

What it means

Thrown from the SWC macro callback in JSTransformer when a macro import resolves to a module that does not expose the requested named export. After require() succeeds and CommonJS default interop is applied (if applicable), Object.hasOwnProperty.call(mod, exportName) is false. The error is caught and re-thrown as a `{kind: 1, message}` object that Rust-side SWC processing recognizes as a macro resolution failure.

Source

Thrown at packages/transformers/js/src/JSTransformer.js:493

      inline_constants: config.inlineConstants,
      callMacro: asset.isSource
        ? async (err, src, exportName, args, loc) => {
            let mod;
            try {
              mod = await options.packageManager.require(src, asset.filePath);

              // Default interop for CommonJS modules.
              if (
                exportName === 'default' &&
                !mod.__esModule &&
                // $FlowFixMe
                Object.prototype.toString.call(config) !== '[object Module]'
              ) {
                mod = {default: mod};
              }

              if (!Object.hasOwnProperty.call(mod, exportName)) {
                throw new Error(`"${src}" does not export "${exportName}".`);
              }
            } catch (err) {
              throw {
                kind: 1,
                message: err.message,
              };
            }

            try {
              if (typeof mod[exportName] === 'function') {
                let ctx: MacroContext = {
                  // Allows macros to emit additional assets to add as dependencies (e.g. css).
                  addAsset(a: MacroAsset) {
                    let k =
                      (asset.uniqueKey ? asset.uniqueKey + ':' : '') +
                      String(macroAssets.length);
                    let map;
                    if (asset.env.sourceMap) {

View on GitHub (pinned to 59484858a1)

Solutions

1. Open the macro-target package and confirm the named export exists (and its spelling).
2. For CommonJS modules, ensure you call a real named property; if you want the whole module use the `default` export name.
3. Pin or upgrade the macro package to the version whose exports you depend on.
4. If you authored the macro module, make sure it is ESM or sets __esModule correctly so interop behaves as expected.

Example fix

// before
import {css} from 'my-macros';
// my-macros only exports `cssMap`
const cls = css`...`;

// after
import {cssMap as css} from 'my-macros';

async function macroExportsExist(specifier, exportName, fromPath) {
  const mod = await import(specifier); // or require, depending on env
  if (!(exportName in mod)) {
    throw new Error(`macro ${specifier} does not export ${exportName}; available: ${Object.keys(mod).join(', ')}`);
  }
  return mod;
}

function hasExport(mod, name) {
  return Object.prototype.hasOwnProperty.call(mod, name);
}

When it happens

Trigger: A `// @macro`-style call site references `import {foo} from 'pkg'` and calls it as a macro, but `pkg` does not export `foo`. Or the default export interop path does not apply and the named export is genuinely absent.

Common situations: Wrong macro name (e.g. calling `css` from a package that exports `cssMap`); package version change that renamed or removed an export; CommonJS interop mismatch where __esModule is not set but default re-wrapping is not triggered because the module looked like an ES module; cyclic import that has not finished evaluating.

Related errors

• "${exportName}" in "${src}" is not a function.
• import() is not allowed in ${asset.env.isWorklet() ? 'workle
• GenericFailure

AI-assisted analysis of parcel-bundler/parcel@59484858a1 (2026-08-13). Data as JSON: /api/errors/63eb08f3980b6d02. Report an issue: GitHub.