vitejs/vite · error · SyntaxError

[vite] The requested module '${rawId}' does not provide an e

Error message

[vite] The requested module '${rawId}' does not provide an export named '${lastBinding}'

What it means

During SSR, Vite rewrites static imports into __vite_ssr_import__ calls and then validates that every named binding the user imported actually exists on the loaded module. For ESM ('module' type) modules, if a named binding is missing, Vite manually throws a SyntaxError mirroring Node.js's native top-level-import error, because SSR transforms imports as dynamic imports and Node would not check named bindings at that point. This emulates correct ESM strictness.

Source

Thrown at packages/vite/src/shared/ssrTransform.ts:43

  rawId: string,
  moduleType: string | undefined,
  metadata?: SSRImportMetadata,
): void {
  // No normalization needed if the user already dynamic imports this module
  if (metadata?.isDynamicImport) return

  // If the user named imports a specifier that can't be analyzed, error.
  // If the module doesn't import anything explicitly, e.g. `import 'foo'` or
  // `import * as foo from 'foo'`, we can skip.
  if (metadata?.importedNames?.length) {
    const missingBindings = metadata.importedNames.filter((s) => !(s in mod))
    if (missingBindings.length) {
      const lastBinding = missingBindings[missingBindings.length - 1]

      // For invalid named exports only, similar to how Node.js errors for top-level imports.
      // But since we transform as dynamic imports, we need to emulate the error manually.
      if (moduleType === 'module') {
        throw new SyntaxError(
          `[vite] The requested module '${rawId}' does not provide an export named '${lastBinding}'`,
        )
      } else {
        // For non-ESM, named imports is done via static analysis with cjs-module-lexer in Node.js.
        // Copied from Node.js
        throw new SyntaxError(`\
[vite] Named export '${lastBinding}' not found. The requested module '${rawId}' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '${rawId}';
const {${missingBindings.join(', ')}} = pkg;
`)
      }
    }
  }
}

View on GitHub (pinned to 89620f09af)

Solutions

Check the actual exports of the module named in the error (rawId) and use a binding that exists.
If the export was renamed in a new version, update the import to the new name.
If only a default export exists, use `import mod from 'rawId'` instead of a named import.

Example fix

// before
import { foo } from './mod' // './mod' has no 'foo' export

// after — use the correct export name (or default)
import { correctName } from './mod'
// or
import mod from './mod'
const { foo } = mod

Defensive patterns

Strategy: type-guard

Validate before calling

// Before relying on a named import in SSR, verify the export exists
import * as knownExports from './mod'
const needed = 'foo'
if (!(needed in knownExports)) {
  throw new Error(`'./mod' does not export '${needed}'`)
}

Type guard

// Runtime check that a binding exists on a loaded module
function hasExport(mod: Record<string, any>, name: string): boolean {
  return name in mod
}

Try / catch

try {
  await ssrLoadModule(url)
} catch (e) {
  if (e instanceof SyntaxError && /does not provide an export named/.test(e.message)) {
    // fix the import binding in the source file named in the error
  } else {
    throw e
  }
}

Prevention

Match import binding names exactly to the module's declared exports.
After upgrading an ESM dependency, re-check its exported names.
Use editor/TS tooling to verify named imports against type declarations.

When it happens

Trigger: An SSR import statement like `import { foo } from './mod'` where './mod' is an ESM module that does not export 'foo'. The analyzeImportedModDifference function detects the missing binding via metadata.importedNames and throws. Only triggered for static (non-dynamic) imports of ESM modules.

Common situations: Importing a named export that was renamed, removed, or never existed in an ESM dependency. Tree-shaking or a version bump that removed an export. Typo in the import binding name. Importing from an ESM module that only has a default export.

Related errors

AI-assisted analysis of vitejs/vite@89620f09af (2026-08-03). Data as JSON: /data/errors/6c37c2d36bc91fac.json. Report an issue: GitHub.