fix(core): dev-mode lingui macro plugin never fires on Windows — admin stuck on loading screen#1941
fix(core): dev-mode lingui macro plugin never fires on Windows — admin stuck on loading screen#1941dchaudhari7177 wants to merge 2 commits into
Conversation
In dev, linguiMacroPlugin gates its transform and locale redirect on id.startsWith(adminSourcePath). Vite module ids use forward slashes on every platform while path.resolve() produces backslashes on Windows, so the prefix check never matched there: admin source reached the browser with raw @lingui/*/macro imports, hydration of every admin island failed (first 'Could not resolve babel-plugin-macros', then 'process is not defined' from the babel machinery landing in the client bundle), and the admin sat on 'Loading EmDash...' forever. Three Windows-specific repairs, all no-ops on POSIX: - compare ids and adminSourcePath in forward-slash space - import @babel/core via pathToFileURL (import() of a bare 'C:...' path parses 'c:' as a URL protocol) - return the locale-catalog redirect as a file:// URL on win32 for the same reason; POSIX keeps the exact same bare path as before Verified on Windows 11: the demo admin setup wizard now hydrates (astro-island count 1, unhydrated 0) where it previously never left the loading screen.
🦋 Changeset detectedLatest commit: b2249d1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
All contributors have signed the CLA ✍️ ✅ |
There was a problem hiding this comment.
Pull request overview
Fixes a Windows-only dev-mode failure where Lingui macros in the admin source weren’t being transformed, causing @lingui/*/macro code to leak into the browser bundle and leaving the admin stuck on “Loading EmDash…”. The change is confined to the Vite integration plugin in packages/core, improving cross-platform path handling without altering POSIX behavior.
Changes:
- Normalize Windows paths to forward-slash form before
startsWithchecks so the Lingui macro transform reliably runs on Windows. - Convert
@babel/coredynamic import to afile://URL to avoid Windows drive-letter ESM import parsing issues. - On Windows only, redirect locale catalog imports to
file://URLs so Node’s ESM loader accepts the resolved paths.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
This is a focused, well-reasoned fix for a real Windows dev-mode breakage. The diagnosis is correct: Vite module IDs use forward slashes, but path.resolve() returns backslashes on Windows, so the linguiMacroPlugin prefix check silently skipped every admin file. The two follow-on Windows landmines — import() of a bare C:\... babel path and the locale redirect reaching Node's ESM loader — are also real. The change is minimal and leaves POSIX behavior byte-for-byte unchanged, which is the right conservative posture.
I checked the diff, the full vite-config.ts, the admin locale loading code (loadMessages.ts / useLocale.ts), existing changesets, and test coverage. The implementation looks correct, but the PR is missing a changeset for the published emdash package, which AGENTS.md requires for any published-package change. I also noted one cosmetic formatting nit.
Headline: fix is correct; add a changeset before merge.
Findings
-
[needs fixing]
packages/core/src/astro/integration/vite-config.ts:1This PR changes
packages/core, a published package (0.29.0), but there is no.changeset/*.mdfor it. AGENTS.md requires a changeset for any published-package change. Since this is a user-visible bug fix (dev mode broken on Windows), it should be documented for the next release.Please add a changeset such as:
--- "emdash": patch --- Fixes admin dev-mode loading screen on Windows by normalizing path separators and converting Windows absolute paths to `file://` URLs for the Lingui macro plugin.
-
[suggestion]
packages/core/src/astro/integration/vite-config.ts:73Nit: add a blank line between the
toPosixPathhelper and thelinguiMacroPluginJSDoc to keep the file consistent with the rest of the codebase.
|
I have read the CLA Document and I hereby sign the CLA |
What does this PR do?
Fixes a Windows-only dev-mode failure where the admin never gets past "Loading EmDash…". Every admin astro-island fails hydration — first
Could not resolve "babel-plugin-macros", thenReferenceError: process is not defined— because the Lingui macro transform is being skipped and raw@lingui/*/macroimports reach the browser.linguiMacroPlugininpackages/core/src/astro/integration/vite-config.tsgates itstransformand locale-catalogresolveIdonid.startsWith(adminSourcePath). Vite ids use forward slashes on every platform, butpath.resolve()returns backslashes on Windows — so the prefix check never matches and the transform silently skips every admin file. Two follow-on Windows landmines sit behind it:await import()of a bareC:\…babel path (Node's ESM loader parsesc:as a URL protocol), and the locale redirect returning a bare Windows path that reaches the ESM loader fromuseLocale.ts.Three fixes, all no-ops on POSIX:
adminSourcePath.import(pathToFileURL(babelCorePath).href).file://URL only on win32 — POSIX returns the identical bare path as before.Closes #
Type of change
Checklist
pnpm typecheckpassespnpm lintpassespnpm testpasses (or targeted tests for my change)pnpm formathas been runmessages.pochanges except in translation PRs — a workflow extracts catalogs on merge tomain.AI-generated code disclosure
Screenshots / test output
Verified on Windows 11 (Node 24, pnpm 11): before — admin permanently on the loading screen with the hydration errors above; after — the setup wizard renders and hydrates cleanly (
document.querySelectorAll('astro-island[ssr]').length === 0), walkable through the Site and Account steps.tsgo --noEmitandoxlint --type-awareonpackages/coreboth pass;prettier --checkis clean. There is no dev-only Vite-plugin test harness in the repo to add a unit test against, so verification is the live Windows repro above.