URL path is incorrect and leads to 404 in app router navigation guard implementation

[ashoofly]

This bug was noticed after v0.2.0 was released.
We noticed a doubling of the basePath in the return URL, and could reproduce it in your example demo.
It did not reproduce when running your example locally though.

To Reproduce

1. Go to https://layerxcom.github.io/next-navigation-guard/page1 and Enable Navigation Guard.
2. Click on 'Page 2' under App Router.
3. After clicking OK and Leave on the dialogs, you are routed to: https://layerxcom.github.io/next-navigation-guard/next-navigation-guard/page2

Notes

• In our app, we have a basePath set in our next.config.js.
• When running in debug mode, I see:

[next-navigation-guard] No original router found

Expected Behavior
Route to https://layerxcom.github.io/next-navigation-guard/page2 instead

[Jonir227]

next-navigation-guard/src/hooks/useInterceptLinkClicks.ts

Line 151 in d77f18f

router.replace(href);

I think this code is the problem.
When basePath is set in Next.js, the path passed to router.push should not include the basePath.
However, this code takes the href directly from the link element, so the resulting navigation path becomes ${basePath}${basePath}${asPath}

I think it should be modified like this:

if (shouldNavigate) {
  debug('All guards passed, navigating programmatically');
  // Navigate programmatically since we prevented the default
  const router = (window as any).next?.router;
  const basePath = router.basePath;
  const asPath = href.replace(basePath, '');

  if (router) {
    if (navigateType === 'replace') {
      router.replace(asPath);
    } else {
      router.push(asPath);
    }
  } else {
    // Fallback to location navigation
    if (navigateType === 'replace') {
      location.replace(href);
    } else {
      location.href = href;
    }
  }
} else {
  debug('Navigation blocked by guard');
}

[jacobrobertsbaca]

@Jonir227 I used your suggestion as a jumping off point and created #43 to fix this. Unfortunately this is not so simple as router.basePath since this property was removed as part of the pages -> app router migration, but I was able to find a workaround. @ypresto can we get a look at this?

[hussam-aldarwish]

👍 Thanks to @jacobrobertsbaca for the clever <Link /> rendering hack to detect the runtime basePath — this is a neat workaround for client-side code in the App Router. It reliably strips the basePath from links so they don’t end up doubled (/admin/admin/...) when using next-navigation-guard.

As an alternative or complementary approach, the package could consider:

1. Using getConfig() (in non-edge environments) to read basePath from next.config.js.
   Please check
   Runtime Config
   getConfig from 'next/config' doesn't work in _middleware.ts

2. Relying on environment variables (like NEXT_PUBLIC_BASE_PATH) to pass the base path explicitly to the client.

Additionally, a temporary middleware-level fix can help for server-side requests, by stripping the basePath if it appears at the start of the pathname:

// middleware.ts
import { NextRequest, NextResponse } from "next/server";

const BASE_PATH = process.env.NEXT_PUBLIC_BASE_PATH || "";

export function middleware(req: NextRequest) {
  const url = req.nextUrl.clone();
  const { pathname } = url;

  // Strip basePath
  if (BASE_PATH && pathname.startsWith(BASE_PATH)) {
    url.pathname = pathname.slice(BASE_PATH.length) || '/';
    return NextResponse.redirect(url);
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!api|static|.*\\..*|_next|health).*)'], // avoid _next, api routes, and static files
};

Notes:

• Query strings and fragments are preserved automatically with NextResponse.redirect.
• Using an environment variable keeps the solution maintainable across different deployments.
• All of these approaches can serve as temporary fixes until next-navigation-guard fully supports basePath in all scenarios.

[ypresto]

Sorry for late response! This is definitely bug and I'll fix it.

[ypresto]

I'll check out #43