vite-plugin-solid

fix: normalize module-url paths to forward slashes on Windows Temporary file — draft body for the PR. Delete before/after opening. Target branch: * (the module-url feature only exists on the 3.x line). Problem The babel pass detects and injects a placeholder as a 2nd argument; the hook then resolves that placeholder to the module's project-relative path and substitutes it back into the emitted source. The path is built with , which returns OS-native separators. On Windows that means backslashes, and the result is spliced straight back into JS source as a string literal: , , etc. are invalid string escape sequences, so the file fails to parse. In practice this breaks dev and build for any route on Windows (the downstream esbuild/rolldown transform throws / ). POSIX is unaffected because already returns forward slashes there — which is why it has gone unnoticed. Where , in the lazy-placeholder resolution loop: No normalization is applied before the path is embedded back into source. Fix Normalize the resolved path to POSIX separators before embedding it. The path is only ever used as a module-url string in generated JS, so forward slashes are always correct (and match what the rest of Vite emits). A small pure helper is added to (its natural home, alongside ): and the call site becomes: That is the entire behavioral change — one helper plus one wrapped call. Tests covers the helper with the built-in runner (no new dependencies): Windows backslashes → forward slashes (the regression) POSIX paths left untouched mixed separators bare filename (no separator) untouched Why a unit test of the helper, and not an example/e2e test The bug is OS-specific: it only reproduces when returns backslashes, i.e. on Windows. The existing example + Cypress/Vitest suites run on Linux CI runners, where already yields forward slashes — so an example-based test could never fail for this bug regardless of the fix. A pure unit test on the normalization function is deterministic on every OS: it feeds a backslash path in and asserts forward slashes out, so it guards the regression on the Linux CI too. How it's wired (and why this way) There is intentionally no new script. The unit suite is run from the existing (already invoked by ), before the example builds, so: Rationale: Single entry point. already drives the whole suite; folding the unit tests in keeps one command and means CI ( → ) picks them up with no workflow changes. Fail-fast. Unit tests run first — fast and cheap — before the heavy + build per example. Streaming output. lets the TAP output pass straight through, and a non-zero exit rejects so the run aborts (and the child is tracked in for the existing cleanup path). Zero new deps / zero config. is built in. Node strips the TypeScript types itself (CI runs Node 23, which does this unflagged; the dir is outside and the rollup entry, so it never leaks into ). Placement / CI note This targets * because module-url resolution only exists there. Heads-up: the workflows currently trigger on only, so a -targeted PR may not auto-run CI until is added to the triggers (left untouched here — maintainer call). Verification → → 4/4 pass → proceeds to . → exit 0; bundle contains . Manually reproduced on Windows: a route 500'd in dev with before the change, renders cleanly after.

Describe The vite:dep-scan:transform:js-glob plugin asserts that the return result is . But the vite-plugin-solid plugin sets . Reproduction https://github.com/zhylmzr/vite-plugin-solid-bug Workarounds 1. move to a single file. 2. or change to:

I think it would be a good idea to try migrating to babel 8 in () branch and I would like to help with that