Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

_seth's avatar
Level 6

Error after publishing with Forge: Page not found: ./Pages/undefined.jsx

I am tracking my Javascript errors with Sentry.

Sentry has been helpful for finding a few issues, but this one I am stumped with. I keep seeing these reports of "Page not found" in Sentry. I cannot reproduce these errors on my development server or visiting the live site.

It is a very small number of reports in proportion to the overall visitors -- less than 0.5%.

I think what is happening is that the user has an old version of the site (i.e. they left their browser open) and the "undefined.jsx" is their browser attempting to pull in the old component.

Given that I'm using Forge, and that things are working pretty well 99% of the time, I'm not sure what the fix is here.

I have implemented code that checks an "/asset-version" route, compares it to the current version, and if it's different it pops a modal to encourage the user to press refresh. This seems to work reliably and prevents the older 404 issues I was having.

Issue occurs on the "resolve" line:

const appName = import.meta.env.VITE_APP_NAME || 'Laravel';
createInertiaApp({
    title: (title) => `${title}`,
    resolve: (name) => resolvePageComponent(`./Pages/${name}.jsx`, import.meta.glob('./Pages/**/*.jsx')),
    setup({ el, App, props }) {

Error:

Page not found: ./Pages/undefined.jsx

Any suggestions?

0 likes
2 replies
LaryAI's avatar
Level 58

The issue you're encountering seems to be related to the dynamic import of your page components using Inertia.js. The error "Page not found: ./Pages/undefined.jsx" suggests that the name variable being passed to the resolvePageComponent function is undefined at some point.

Here are a few steps you can take to troubleshoot and potentially resolve this issue:

  1. Check Route Definitions: Ensure that all your routes are correctly defined and that they map to existing components. A missing or incorrect route could lead to an undefined page name.

  2. Default Fallback: Add a default fallback in your resolve function to handle cases where name might be undefined. This can help prevent the error from propagating and provide a more graceful failure.

    resolve: (name) => {
        if (!name) {
            console.error('Page name is undefined');
            return import('./Pages/NotFound.jsx'); // or any fallback component
        }
        return resolvePageComponent(`./Pages/${name}.jsx`, import.meta.glob('./Pages/**/*.jsx'));
    },
    
  3. Error Logging: Add additional logging to capture more context about when and why name might be undefined. This can help you identify patterns or specific routes that are causing the issue.

  4. Cache Busting: Since you suspect that users might be seeing an old version of the site, ensure that your deployment process includes cache busting for your JavaScript files. This can be done by appending a version or hash to your asset URLs.

  5. User Notification: You mentioned already implementing a version check. Ensure that this is robust and that users are clearly notified when they need to refresh their browser.

  6. Sentry Context: Use Sentry's context features to capture additional information about the user's environment when the error occurs. This might include the URL, user agent, or any other relevant data.

By implementing these steps, you should be able to reduce the occurrence of this error and gain more insight into its root cause. If the issue persists, consider reviewing your deployment and build processes to ensure that all assets are correctly updated and served.

_seth's avatar
Level 6
  1. Route definitions are good. I would expect to see a 404 on my end if there was an issue. I can look at the screen capture to see what the user is doing -- I'm sure my routes are okay.
  2. The default fallback seems like an OK way of suppressing the error message, but the issue is that the page seems to be pulling in a component it cannot access. So displaying a 404 would not necessarily be helpful to me. The users are not seeing a 404 error anyway.
  3. Error Logging results:
    • 123 errors captured
    • 74% on Chrome mobile
    • 92% on "K" device (interesting... this seems to be a Chinese device?)
    • 87% on Android
    • 85% on Android 10
  4. Cache busting is implemented with Vite. I think this is part of the problem, the errors happen with new releases.
  5. Instead of requesting the users refresh their browser (with a modal "Refresh" button), I may force the refresh. I do a popup in case they are entering content and don't want to lose it.
  6. It happens across different pages, but mainly on "K" device and older Android. It would seem to be a cache related issue on these older phones. The page is already set to "no-cache" so it's odd that is happening.

Please or to participate in this conversation.