Skip to content

"Couldn't resolve component 'default' at '/destinations'" when using lazy-loaded components #2477

@akumanara

Description

@akumanara

Reproduction

Steps to reproduce the bug

It's very difficult to provide a minimal reproduction since this issue only happens in production with cached assets after deployment, but here's my best attempt to explain the reproduction steps:

Build and deploy a Vue application with lazy-loaded routes using Vue Router
Users visit the site and the JavaScript chunks are cached in their browsers
Deploy a new version with updated code/dependencies (different hashed filenames)
Users who previously visited the site (with cached chunks) return
Vue Router attempts to load a lazy-loaded component but fails with error: Couldn't resolve component "default" at "/XXXXXX"

The error specifically occurs in the component resolution process where componentPromise.then(resolved) receives a falsy value, triggering the error in the extractComponentsGuards function.

This is likely related to cached chunks being invalidated or mismatched versions of files being loaded during the component resolution process.

Expected behavior

Provide a more graceful fallback or retry mechanism when component resolution fails due to potentially stale cached assets.

When a component fails to load due to caching issues or deployment timing, the router should have a built-in recovery mechanism rather than failing with a cryptic error message. This could include automatic retries, falling back to a network request for the new chunk, or triggering a page refresh when it detects mismatched versions.

Additionally, the Vue Router documentation should include information about potential issues with deployments and cached components in the lazy-loading routes section. This would help developers implement proper caching strategies and understand how to prevent such errors in production environments.

Actual behavior

The router throws an uncaught error: Couldn't resolve component "default" at "/destinations" which crashes the application.

Additional information

Application Setup

My application is built with Vite and uses content hashing for output files
We deploy using Docker containers to DigitalOcean App Platform

Potential Solutions
Writing some potential solutions to help someone else visiting this issue:

  • Service Worker Implementation
  • Improved Cache Headers
  • Atomic Deployments
  • Error Handling Wrapper

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions