Missing dynamic types with Typed Routes + Parallel Routes when doing production build?

[subvertallchris]

Summary

Hi all. I'm trying to track down a very tricky bug that occurs when I run a production build. I'm using Next.ja 14.1.4 but it also happens with 14.2.0-canary.44. The conditions:

• TypeScript 5.4.2 but I downgraded as far as 4.5.2 just to be sure
• Using typedRoutes
• Using one parallel route with a dynamic path
• Dev mode works fine
• When I run a build, the DynamicRoutes types in __next_route_internal_types__ does not include the dynamic route that matches the dynamic path.

I've been troubleshooting for hours. I know the following:

• If I comment out enough lines in the default route's page.tsx, it will work.
• It doesn't seem like any one thing upsets it. At one point, I was convinced it was this particular link-parsing utility function. Another time it wanted me to delete a few keys from the exported metadata object from that same component. Right this second, it's a React component that provides an SVG.
• It's something about the data returned from the component, not an import. For instance, I can comment out a line being returned and it will work even though the same files are imported.

It has the feel of error that's being caught and not returned to the UI. I'm tempted to say circular dependency but I can't seem to figure out what it doesn't like.

I've been trying to pin this down for hours, almost my entire work day so far, and I can't seem to get it. I'm opening as a discussion because I can't reproduce it in a Codesandbox, which suggests it's something in my codebase, but nothing jumps out.

I would really like to avoid asserting types on this path, it's an important one. It makes me even more hesitant to use Parallel Routes because I don't know what else will pop up once I depend on it.

Has anyone encountered this? Any tips?

Additional information

No response

Example

No response

[kristian240]

I had a similar issue and I found a potential workaround but it requires a minor change in next package in next-types-plugin part of the module.

I noticed that route/page urls are retrieved by utilizing JS chunks that webpack generates - source. For every chunk there are some connected chunks that are retrieved by calling a getChunkModulesIterable method.

Further, I noticed that there are multiple chunk types but all route types are retrieved from NormalModule chunks.

However, in some cases, the route path is not retrievable because resource is an empty string.

To temporarily fix the issue on our end I added these lines between for loop and promises.push call

if (mod.constructor.name === 'NormalModule' && !mod.resource) {
  mod.resource = chunk.name.replace(/^app/, this.appDir) + '.tsx';
}

this will populate the resource and mentioned guard where resource is checked will pass.

I do not understand the modules and chunk part in order to fully fix the issue but I hope that this helps. Maybe someone from Vercel team can help us here? cc: @leerob

NOTE 1: as a result I get type where a page/route is duplicated but since this is a type union it does not matter.

NOTE 2: this happened only when parallel route was added; it was working correctly before

NOTE 3: I have a setup where inside route group I have a layout and parallel route and there is also a route group nested inside of it. Also there is a catch all route in one case.

NOTE 4: grouping the routes in the same way in app and in parallel route made no difference

NOTE 5: All sidebar implementetion extend the default one by importing it in the module, not sure if that can cause any issues.

[koka0012]

That's funny because I started getting the same kind of error. And after reading this I noticed that was after I began to use parallel routes.
Unfortunately, I tried to find a way to fix the issue in the next-types-plugin, but I had no luck.
This issue may need to be addressed ASAP, especially if parallel routes start to be more popular.

[controversial]

@koka0012 the following patch is working for me in next-types-plugin:

@@ -521,7 +521,19 @@ class NextTypesPlugin {
                         if (!chunk.name.startsWith("pages/") && !(chunk.name.startsWith("app/") && (chunk.name.endsWith("/page") || chunk.name.endsWith("/route")))) {
                             return;
                         }
-                        const chunkModules = compilation.chunkGraph.getChunkModulesIterable(chunk);
+
+                        // Hack for bug where some routes are missing from typedRoutes generated in prod
+                        const chunkModules = [...compilation.chunkGraph.getChunkModulesIterable(chunk)];
+                        if (chunkModules.every((mod) => !mod.resource)) {
+                            console.warn('Patching broken modules for ', chunk.name);
+                            const fakeModules = [...chunk.files]
+                                .map((file) => ({
+                                    resource: _path.default.join(chunk.name.startsWith('app/') ? this.appDir : this.pagesDir, file),
+                                    layer: _constants.WEBPACK_LAYERS.appRouteHandler,
+                                }));
+                            chunkModules.push(...fakeModules);
+                        }
+
                         for (const mod of chunkModules){
                             promises.push(handleModule(mod, assets));
                             // If this is a concatenation, register each child to the parent ID.

[subvertallchris]

I have serious concerns about the future of Typed Routes. No updates in quite a while, there’s no indication that it is planned for leaving “experimental” status, and show-stopping bugs like this remain unaddressed. Is it even compatible with turbo yet? Last I checked it was not.

[controversial]

In #67891 the other day @timneutkens wrote

it will be implemented after stable

about typedRoutes support for turbopack

[sleepdotexe]

Are there any updates on this issue? I believe I'm still encountering the same thing as of next@14.2.12. Super annoying issue considering it causes the build step to fail out entirely, meaning I need to either remove all the Route typings and disable typedRoutes or cast a bunch of as Route all over the place.

[sleepdotexe]

Ok well, after doing some thorough ripping apart of my repo, I've managed to narrow down why this appears to be happening. It seems like it might have to do with the React Context API.

In my instance at least, I am trying to use parallel routes to set up a simple "breadcrumbs" section in shared layouts. I have a folder structure that looks like this in part:

app/
  [team]/
    @breadcrumbs/
      default.tsx
      page.tsx
    /order/[item]/
      page.tsx
    layout.tsx
    page.tx
  admin/
    @breadcrumbs/
      default.tsx
      page.tsx
    layout.tsx
    page.tx 

Here is what I am expecting in .next/types/link.d.ts:

type StaticRoutes = 
    // ...
    | `/app/admin`
    // ...

type DynamicRoutes<T extends string = string> = 
    // ...
    | `/app/${SafeSlug<T>}`
    | `/app/${SafeSlug<T>}/order/${SafeSlug<T>}`
    // ...

Here's an outline of some of the behaviors I'm seeing:

Issue with .../app/[team]/layout.tsx

This file looks something like this:

const contextPromise = getMyContext();

// doesn't work
return (
  <MyContextProvider contextPromise={contextPromise}>
    <Header breadcrumbs={breadcrumbs} />
    <main>{children}</main>
  </MyContextProvider >
);

// works
return (
  <>
    <Header breadcrumbs={breadcrumbs} />
    <main>{children}</main>
  </>
);

When I add the MyContextProvider wrapper, /app/admin disappears from StaticRoutes. This one is bizarre, since this is in a separate subfolder to the admin route so I have no idea why this would affect it. If I replace it with a React fragment <>...</>, then it compiles as expected (assuming the issues below are also removed).

Issue with .../app/[team]/order/[item]/page.tsx

This file looks something like this:

// doesn't work
return (
  <Section>
    <h1>{item.title}</h1>
    <AddToOrder>Add to order</AddToOrder>
  </Section>
);

// works
return (
  <Section>
    <h1>{item.title}</h1>
    {/* <AddToOrder>Add to order</AddToOrder> */}
  </Section>
);

Under the hood, <AddToOrder> calls a useContext hook for the context from the previous issue. If I comment out the button line, the app compiles as expected (assuming the other issues are also fixed). With the button left in, both /app/admin and /app/${SafeSlug<T>}/order/${SafeSlug<T>} disappear from the Route types.

Issue with .../app/admin/page.tsx

This file looks something like this:

// doesn't work
return (
  <Section>
    <h1>Admin dashboard</h1>
    <SignOutButton>Sign out</SignOutButton>
  </Section>
);

// works
return (
  <Section>
    <h1>Admin dashboard</h1>
    {/* <SignOutButton>Sign out</SignOutButton> */}
  </Section>
);

Under the hood, <SignOutButton> calls a useContext hook (for a different context provide to the previous issue). If I comment out the button line, the app compiles as expected (assuming the other issues are also fixed). With the button left in, /app/admin disappears from StaticRoutes.

If I remove both of the @breadcrumbs folders...

It compiles fine with no errors, even with all of the other errors above left unchanged. Both of my expected Route types exist in .next/types/link.d.ts.

Conclusion

It appears there is some issue with parallel route folders and the React Context API. It seems like if you try to add a context provider or use the context within a route that uses parallel routes it breaks in multiple locations.

I haven't managed to work out a fix just yet (that doesn't involve removing one or the other) or produce a working minimal repro. Hopefully this gives the team a direction to investigate?

[oyrad]

Any news on this issue with parallel routes?