Invariant: attempted to hard navigate to the same URL (Rewrites inside next.config.mjs)

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Deployed to Vercel

      Platform: win32
      Arch: x64
      Version: Windows 10 Pro
    Binaries:
      Node: 16.13.1
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.2.6-canary.0
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

What browser are you using? (if relevant)

Not relevant

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

When creating rewrites from next.config.mjs, that include a trailing slash in the source, and/or rewriting from a source to a destination with a slug { source: "/test/", destination: "/test/1/" } will cause errors in production that will cause the page to reload and throws an error.

Errors: Failed to lookup route: / The provided 'as' value (/test/) is incompatible with the 'href' value (/test/[slug]) Invariant: attempted to hard navigate to the same URL /

On the minimal reproduction, errors can be seen when clicking on the home button twice. For the first group of links 1,3,4 (links 2, 2.5 apparently work because /test.js file actually exists) It appears as though a root index file is needed in a folder that has a dynamic route in order to prevent the errors from occurring even though the path should be getting rewritten to the dynamic destination.

The second “fix” is from removing the trailing slash from the source. I have no idea why removing the trailing slash from the rewrite source prevents the errors above from happening but I wouldn’t really call that a solution to the problem as you can’t really remove the trailing slash from the home page ‘/’. You can see that removing the trailing slash does not throw errors in the reproduction with the second group of links.

In development, the network tab shows that the router is requesting the wrong JavaScript file for the page and seems to be ignoring the rewrite from the manifest (Cannot be seen in Vercel reproduction).
I believe whatever is causing this bug is the same bug for https://github.com/vercel/next.js/issues/38171 as it follows a similar premise using rewrites and in development, an extra page.js fetch can be seen before the page reload with a Failed to load script: /_next/static/chunks/pages/test.js error.

Expected Behavior

Should work the same way as 12.1.4 where rewrites do not throw errors on page load.

Link to reproduction

https://next-12-2-4-rewrite-bug.vercel.app

To Reproduce

Minimal reproduction repo: https://github.com/grayaustinc/next-12.2.4-rewrite-bug (is now on version: next@canary) Create rewrites in next.config.mjs where the source does not contain the slug (with a trailing slash) and the destination with the slug included. { source: "/test/", destination: "/test/1/" } More simply, a source/destination for the home page { source: "/", destination: "/home/" }

[msampsontruecar]

I’ve been seeing the same issue. I tracked it down to this change made in 12.2.1. https://github.com/vercel/next.js/pull/38282/files#diff-c63f939297887175342bae28f4c0e69f1e6b10149cb43795390356d1d771a6f2R38

Adding (/)? to the end of the source pattern if config is set for trailingSlash: true

    const matcher = getPathMatch(
      rewrite.source + (process.env.__NEXT_TRAILING_SLASH ? '(/)?' : ''),
      {
        removeUnnamedParams: true,
        strict: true,
      }
    )

Reverting the change would fix it for us but we would reintroduce the issue for people who don’t have trailing slashes on the end of their rewrite sources and have trailingSlash: true.

I’ll have to look into it more but there may be some issue with using (/)? with pathToRegexp since the delimiter is set to /.

One possible solution that I think covers all use cases and avoids adding extra pattern matching. Although I’m not sure it is safe to make assumptions about what a rewrite source will end with so more testing is needed.

    const matcher = getPathMatch(
      !rewrite.source.endsWith('/') && process.env.__NEXT_TRAILING_SLASH
        ? rewrite.source + '/'
        : rewrite.source.endsWith('/') && !process.env.__NEXT_TRAILING_SLASH
        ? removeTrailingSlash(rewrite.source)
        : rewrite.source,
      {
        removeUnnamedParams: true,
        strict: true,
      }
    )

If no one gets to it before me I can investigate further and work on a PR next week.

[grayaustinc]

Updated the reproduction to use Next 13 and continue to have same issues. A temporary fix is to add {/}? to end of sources (As explained on issue #40549 ).