vitejs/vite · error · Error

Unable to parse: ${filePath}.

Error message

Unable to parse: ${filePath}.

What it means

While extracting a dependency's exports, Vite first parses the entry with oxc; if that fails it retries through a configured `moduleTypes` loader (defaulting to `jsx`). If the resolved loader is not one of `jsx`/`tsx`/`ts`, there is no fallback transform and it throws at optimizer/index.ts:1170. This guards against unsupported file types reaching the optimizer.

Source

Thrown at packages/vite/src/node/optimizer/index.ts:1170

    return {
      hasModuleSyntax,
      exports: exports.map((e) => e.n),
    }
  }

  let parseResult: ReturnType<typeof parse>
  let usedJsxLoader = false

  const entryContent = fs.readFileSync(filePath, 'utf-8')
  try {
    parseResult = parse(entryContent)
  } catch {
    const lang = rolldownOptions.moduleTypes?.[path.extname(filePath)] || 'jsx'
    debug?.(
      `Unable to parse: ${filePath}.\n Trying again with a ${lang} transform.`,
    )
    if (lang !== 'jsx' && lang !== 'tsx' && lang !== 'ts') {
      throw new Error(`Unable to parse: ${filePath}.`)
    }
    const transformed = await transformWithOxc(
      entryContent,
      filePath,
      { lang },
      undefined,
      environment.config,
    )
    parseResult = parse(transformed.code)
    usedJsxLoader = true
  }

  const [, exports, , hasModuleSyntax] = parseResult
  const exportsData: ExportsData = {
    hasModuleSyntax,
    exports: exports.map((e) => e.n),
    jsxLoader: usedJsxLoader,
  }

View on GitHub (pinned to 89620f09af)

Solutions

  1. Ensure the dependency's entry is real JS/TS; if the package points `main`/`module` at a non-JS file, file an issue with the package or alias it.
  2. Map the extension to `jsx`/`tsx`/`ts` in `optimizeDeps.esbuildOptions` so the fallback transform can run.
  3. Add the package to `optimizeDeps.exclude` so the optimizer doesn't try to pre-bundle it.
  4. Update the package — newer versions often fix entry/metadata issues.

Example fix

// before
optimizeDeps: { esbuildOptions: { loader: { '.myext': 'text' } } }

// after
optimizeDps: { exclude: ['problematic-pkg'] }
// or
optimizeDeps: { esbuildOptions: { loader: { '.myext': 'jsx' } } }
Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED = new Set(['jsx', 'tsx', 'ts'])
function assertLoaderFor(ext: string, moduleTypes: Record<string, string>) {
  const lang = moduleTypes[ext] || 'jsx'
  if (!SUPPORTED.has(lang)) throw new Error(`Optimizer cannot parse .${ext}; map it to jsx/tsx/ts or exclude the dep`)
}

Type guard

function isOptimizableLoader(lang: string): boolean {
  return lang === 'jsx' || lang === 'tsx' || lang === 'ts'
}

Prevention

When it happens

Trigger: A dependency whose entry file has an extension mapped to a non-JS moduleType in `optimizeDeps.esbuildOptions.moduleTypes`/`build.moduleTypes` (e.g. `.txt`, `.wasm`, a custom loader), or a file oxc cannot parse and whose configured loader isn't jsx/tsx/ts.

Common situations: A package ships a non-standard entry extension; user sets `esbuildOptions.loader`/`moduleTypes` to map an extension to `text`/`base64`/`json` and that file ends up as a dep entry; corrupt or transpiled-with-syntax-not-supported-by-oxc files.

Related errors


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