docs: compound Vite API proxy source-module fix#1507
Conversation
📝 WalkthroughWalkthroughAdded a new documentation article describing a Vite dev-server proxy misconfiguration in the dashboard where the ChangesVite Proxy Integration Issue Documentation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR adds a solution document capturing the root cause, failed approaches, final fix, and prevention guidance for the case where Vite's dev-server proxy was forwarding source-module requests (
Confidence Score: 4/5Documentation-only change; the documented regex is a verbatim copy of the live vite.config.ts implementation, both related cross-links resolve, and the frontmatter passes validation. The document is accurate and well-structured. The only gap is that the "Why This Works" section explains the negative lookahead in detail but does not mention the (/|$) suffix that handles top-level paths like /api.ts and /api-node.ts, creating a small blind spot for readers following just that explanation. The new solution document is the only file changed; the regex explanation section is the one area worth a second read. Important Files Changed
Sequence DiagramsequenceDiagram
participant Browser
participant Vite as Vite Dev Server
participant Backend as Backend API (port 4040)
Note over Browser,Backend: /api/health → proxied (no source-module extension)
Browser->>Vite: GET /api/health
Vite->>Backend: proxy (regex matches)
Backend-->>Browser: 200 JSON
Note over Browser,Vite: /api/legacy.ts → served by Vite (lookahead fires)
Browser->>Vite: GET /api/legacy.ts
Vite-->>Browser: 200 JS module (regex does NOT match)
Note over Browser,Vite: /api/legacy.ts?import → served by Vite (? after extension caught)
Browser->>Vite: GET /api/legacy.ts?import
Vite-->>Browser: 200 JS module (regex does NOT match)
Note over Browser,Vite: /api.ts → served by Vite ((/|$) fails, . after /api)
Browser->>Vite: GET /api.ts
Vite-->>Browser: 200 JS module (regex does NOT match)
Reviews (1): Last reviewed commit: "docs: compound Vite API proxy source mod..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| The negative lookahead rejects source-module extensions before the proxy claims the request: | ||
|
|
||
| - `/api/health` matches the proxy and reaches the backend. | ||
| - `/api/legacy.ts` does not match the proxy and stays on Vite. | ||
| - `/api/legacy.ts?import` also stays on Vite because the source-extension check allows an optional query string. | ||
| - `.tsx`, `.js`, and `.jsx` are excluded too so future source modules do not rediscover the same failure. |
There was a problem hiding this comment.
(/|$) suffix at the end of the regex is actually what keeps /api.ts and /api-node.ts on Vite — the character immediately after /api in those URLs is . or -, not / or end-of-string, so the regex never reaches the lookahead. A reader might wonder how /api.ts (mentioned in Symptoms) is excluded if the only listed examples in this section are /api/... paths. Adding one explicit example makes the full regex behavior clear.
| The negative lookahead rejects source-module extensions before the proxy claims the request: | |
| - `/api/health` matches the proxy and reaches the backend. | |
| - `/api/legacy.ts` does not match the proxy and stays on Vite. | |
| - `/api/legacy.ts?import` also stays on Vite because the source-extension check allows an optional query string. | |
| - `.tsx`, `.js`, and `.jsx` are excluded too so future source modules do not rediscover the same failure. | |
| The negative lookahead rejects source-module extensions before the proxy claims the request, and the trailing `(/|$)` anchor ensures the regex only fires on real API path prefixes: | |
| - `/api/health` matches the proxy and reaches the backend. | |
| - `/api/legacy.ts` does not match the proxy and stays on Vite. | |
| - `/api/legacy.ts?import` also stays on Vite because the source-extension check allows an optional query string. | |
| - `/api.ts` and `/api-node.ts` stay on Vite because the character after `/api` is `.` or `-`, not `/` or end-of-string, so `(/|$)` fails before the lookahead is even evaluated. | |
| - `.tsx`, `.js`, and `.jsx` are excluded too so future source modules do not rediscover the same failure. |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@docs/solutions/integration-issues/vite-api-source-modules-proxied-to-backend.md`:
- Around line 85-94: Update the explanation around the proxy regex (the
caret-anchored pattern with the negative lookahead) to explicitly state how it
treats top-level source-module filenames like "/api.ts" and "/api-node.ts" as
well as nested paths such as "/api/legacy.ts"; mention that the negative
lookahead excludes extensions (.ts, .tsx, .js, .jsx) immediately following the
"/api" prefix or directly after "/api" (so "/api.ts" and "/api-node.ts" are kept
by Vite), and if you changed the regex per the prior comment, update the wording
to reflect the corrected pattern behavior and examples.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: daeaff7c-2eff-443f-baeb-c4ce718da59d
📒 Files selected for processing (1)
docs/solutions/integration-issues/vite-api-source-modules-proxied-to-backend.md
| ## Why This Works | ||
|
|
||
| Vite treats proxy keys beginning with `^` as regular expressions matched against the request URL. The dashboard has source modules whose served URLs begin with `/api`, while the backend API namespace also begins with `/api`; a prefix rule cannot distinguish them. | ||
|
|
||
| The negative lookahead rejects source-module extensions before the proxy claims the request: | ||
|
|
||
| - `/api/health` matches the proxy and reaches the backend. | ||
| - `/api/legacy.ts` does not match the proxy and stays on Vite. | ||
| - `/api/legacy.ts?import` also stays on Vite because the source-extension check allows an optional query string. | ||
| - `.tsx`, `.js`, and `.jsx` are excluded too so future source modules do not rediscover the same failure. |
There was a problem hiding this comment.
Clarify the regex explanation for top-level source modules.
The explanation focuses on nested paths like /api/legacy.ts but doesn't explicitly address how the regex handles top-level files like /api.ts and /api-node.ts mentioned in the symptoms. If the regex needs adjustment (per the previous comment), this explanation should be updated to match the corrected pattern.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@docs/solutions/integration-issues/vite-api-source-modules-proxied-to-backend.md`
around lines 85 - 94, Update the explanation around the proxy regex (the
caret-anchored pattern with the negative lookahead) to explicitly state how it
treats top-level source-module filenames like "/api.ts" and "/api-node.ts" as
well as nested paths such as "/api/legacy.ts"; mention that the negative
lookahead excludes extensions (.ts, .tsx, .js, .jsx) immediately following the
"/api" prefix or directly after "/api" (so "/api.ts" and "/api-node.ts" are kept
by Vite), and if you changed the regex per the prior comment, update the wording
to reflect the corrected pattern behavior and examples.
1 participant
Summary
/api*source-module requests were proxied to the backend.Verification
python3 plugins/fusion-plugin-compound-engineering/src/skills/ce-compound/scripts/validate-frontmatter.py docs/solutions/integration-issues/vite-api-source-modules-proxied-to-backend.mdSummary by CodeRabbit