fix: define location in the entrypoint environment

[ethanstoner]

Closes #2601.

What was wrong

getBrowserEnvironmentGlobals hands entrypoint evaluation LinkeDOM's window and document, but no location. Confirmed against linkedom 0.18.13:

typeof window        : object
typeof document      : object
'location' in window : false
window.location      : undefined
reading .href THROWS : TypeError: Cannot read properties of undefined (reading 'href')

That is the worst combination for browser-detecting dependencies. They check typeof window !== 'undefined' && typeof document !== 'undefined', conclude they are in a browser, and then read window.location while the module is still initializing. Axios 1.18.1 does exactly this, and wxt prepare dies before it can generate types, with the error above.

The fix

Define an inert location on window, on the LinkeDOM global (so self.location resolves too), and in the returned globals so applyGlobals puts it on globalThis.

It is a read-only stand-in pointing at http://localhost/, carrying the fields detection code actually reads: href, protocol, host, hostname, origin, port, pathname, search, hash, plus toString. There is no page to navigate at build time, so assign, reload and replace are no-ops rather than throwing.

A plain URL was the obvious choice and does not typecheck: window.location is typed string & Location, and URL is missing ancestorOrigins, assign, reload and replace. Hence the small Location-shaped helper and one narrow cast at the window.location assignment, which nothing can satisfy honestly.

Testing

New browser-environment.test.ts, 4 tests. All 4 pass with the change and all 4 fail without it, the key one failing with the issue's exact error:

TypeError: Cannot read properties of undefined (reading 'href')
     41|         return window.location.href;

One of them reproduces the real shape of the bug rather than just asserting the field exists: it runs inside env.run, asserts hasBrowserEnv is true, and then reads window.location.href.

Full packages/wxt suite on Windows: 52 files passed, 550 tests passed, 4 skipped, 2 todo, 0 failed.

tsc --noEmit is clean and prettier --check passes on both files.

Worth flagging honestly: an earlier full-suite run showed e2e/tests/wxt.test.ts failing with EADDRINUSE ... ::1:3000. That test deliberately occupies port 3000, it passed twice in isolation with this change applied, it passed on a baseline run, and the final full run above is green. It was leaked processes from my repeated runs, not this diff.

Not verified

I did not run the gist reproduction end to end with axios installed; the tests above model the same failure directly against the environment. I also have not checked the extension environment path beyond it reusing getBrowserEnvironmentGlobals.

Happy to change the placeholder URL if you would rather it were something else, or make it configurable.

AI usage

Claude Code (Claude Opus 5) helped investigate and write this; I reviewed the diff and ran everything above myself.

[netlify]

✅ Deploy Preview for creative-fairy-df92c4 ready!

Name	Link
🔨 Latest commit	9c082d4
🔍 Latest deploy log	https://app.netlify.com/projects/creative-fairy-df92c4/deploys/6a9cc81cac510500083e3fe5
😎 Deploy Preview	https://deploy-preview-2611--creative-fairy-df92c4.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.