v1.132.2 basePath is not working for browser url

[leesb971204]

Which project does this relate to?

Router

Describe the bug

Since that version, basepath has been replaced with the rewrite method, and it seems that the rewrite logic has been applied to basepath for backward compatibility with previous versions.

When basepath is configured the same way as in earlier versions, accessing without a basepath (e.g., http://localhost:3000) does not add the basepath to the browser URL.

Your Example Website or App

https://stackblitz.com/edit/github-lebazlff?file=src%2Froutes%2F__root.tsx

Steps to Reproduce the Bug or Issue

1. check window.location.pathname in /home
2. click about
3. check window.location.pathname in /about

Expected behavior

window.location.pathname in home should be /app

Screenshots or Videos

No response

Platform

• Router / Start Version: [e.g. 1.121.0]
• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Browser Version: [e.g. 91.1]
• Bundler: [e.g. vite]
• Bundler Version: [e.g. 7.0.0]

Additional context

No response

[reihwald]

There are still issues in the newest version when using throw redirect: https://stackblitz.com/edit/github-m8qo8ju3?file=src%2Fmain.tsx

The "About" link includes the basepath but the beforeLoad redirect to /other (should be /basepath/other) omits it

[nlynzaad]

@leesb971204 see the updated stackblitz apart from the bump in versions I added the base to the vite cconfig

[nlynzaad]

@reihwald @leesb971204 I picked up some issues in the rewrite code path. @leesb971204 while it is still recommended to add the base in the vite config as this is where the application is mounted this also seems to resolve your issue.

@reihwald the fix also addresses your issue with the redirects, I've added an e2e test to this as well to ensure redirects with basePaths work as intended going forward.

[nlynzaad]

@reihwald the issues experienced with redirects is resolved in the latest release 1.143.4.

@leesb971204 the app needs to be mounted on the correct path for initial render to be done on the correct path. router will only start rewriting the urls once router is doing the necessary navigations. in dev on vite this can be done by setting the base to /basepath the basepath in router should be set to correspond to this, while on prod this will be the path that the app is being served on from your server.

[leesb971204]

@nlynzaad
I'm sorry, but could you help me understand why, in the StackBlitz I reproduced, the initial useLocation().location.pathname is '/' and after visiting the About page and navigating back to Home, window.location.pathname becomes '/app/about'?

Note: Vite’s base is set to '/app' and router version is 1.143.4.

[nlynzaad]

@leesb971204 I'm not able to recreate what you are seeing.

I opened your stackblitz, ran it and opened the preview page so that the path can be seen clearly and initial render is done to /app

I also ran it locally and initial path is /app

note you should see vite clearly indicating your path

VITE v7.3.0  ready in 286 ms

  ➜  Local:   http://localhost:3000/app
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

[nlynzaad]

I think I see what you are referring to now, I'll investigate and advise.

This works correctly with the window.location.pathname called from within the route, but is showing the previous route when called from the root layout. This doesn't seem to be related to basepath however as this behaviour is reproducible with and without the basepath.

Could you please create a new issue with this behaviour specifically, you could do this with or without the basepath set. I will be able to look at it in the next couple of days.

[leesb971204]

@nlynzaad
Yes, as you probably noticed, while window.location.pathname is now working as expected, useLocation().location.pathname behaves differently between the old version and the latest one — just as I reproduced here.

[leesb971204]

And one more thing I’d like to ask —
In earlier versions, even without setting the base in vite.config.ts , window.location.pathname would reflect the basePath (as far as I remember, this applied even in production builds).
But now that’s no longer the case.

Does that mean the behavior in the previous versions was actually incorrect?