Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

lazy() moduleUrl with a leading slash never resolves: dev emits `//src/…`, the build manifest lookup misses

Ouverte
  • Quelque chose ne va pas ?
#390 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript, vite
Domaine
build-system, tooling

Piste de recherche

Start with devModuleUrl in src/dev-manifest.ts and the mirrored moduleUrl() in the generated devManifestCode in src/index.ts, then inspect manifest[moduleUrl] in packages/web/src/server.ts. Run the solid-v2/fullstack reproduction in the linked issue for both dev and production builds. Done means a leading-slash moduleUrl resolves consistently in both modes, or is rejected with a clear format error.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

A lazy() call whose hand-written moduleUrl has a leading slash ("/src/Page.tsx") never resolves. The plugin's key format is project-relative (src/Page.tsx), and nothing normalizes the slash:

  • Dev: the generated URL becomes protocol-relative (//src/Page.tsx). The preload fetches http://src/Page.tsx and fails, and hydrate() falls back to a client render.
  • Build: the client manifest has no /src/Page.tsx key. The server logs Asset manifest returned no client assets for module "/src/Page.tsx" and ships no root module map. On the client, hydration throws lazy() module "/src/Page.tsx" … was not preloaded before hydration, and reactivity halts.

This was split out of solidjs/solid#3338, where it reproduced the reporter's "page looks hydrated but every signal is dead" symptom.

Reproduction

From the reproduction on solidjs/solid#3338: the solid-v2/fullstack template (solid-js / @solidjs/web 2.0.0-rc.6, @solidjs/router 2.0.0-next.21, @solidjs/vite-plugin 3.0.0-next.39), with the <Loading> removed and a route component declared as:

const Page = lazy(() => import("./Page"), undefined, "/src/Page.tsx");
  • Production build: the server logs Asset manifest returned no client assets for module "/src/Page.tsx". The client throws lazy() module "/src/Page.tsx" (hydration id "…") was not preloaded before hydration from the router outlet. Reactivity halts (REACTIVITY_HALTED).
  • Dev: the root module map is serialized as //src/Page.tsx. The preload requests http://src/Page.tsx, fails, and the fallback client render dies with an unhandled Hydration Mismatch … key: undefined.

The same key without the slash ("src/Page.tsx") hydrates and stays reactive in both modes. See also the first diagnosis comment.

Expected behavior

A leading / on a moduleUrl key names the same module as the project-relative key. Either:

  • it's normalized (/src/Page.tsx → src/Page.tsx) before the dev URL is built and before the build-manifest lookup, so both modes resolve the module; or
  • if a leading slash is meant to be invalid, it's rejected with a clear error naming the expected project-relative format, not a silent miss.
Where it likely lives

A hand-written third argument bypasses the compiler's lazy() pass (transformLazy only rewrites one- and two-argument calls). So the user's string reaches the resolvers as-is.

  • Dev: devModuleUrl in src/dev-manifest.ts and its mirror moduleUrl() in the generated devManifestCode in src/index.ts. Both build base + "/" + key, which gives //src/Page.tsx for a slash-prefixed key. The comment on devManifestCode says to keep the two in sync.
  • Build: the virtual:solid-manifest load hook in src/index.ts exports the raw Vite manifest (via stampClientEntry). The key lookup itself is manifest[moduleUrl] in @solidjs/web's resolveAssets (packages/web/src/server.ts in solidjs/solid). The production half could be fixed on either side: the plugin normalizing keys in what it exports, or the runtime normalizing before lookup. That's worth deciding before a fix, so dev and build agree.

Related but distinct: #263 (Windows separators in generated keys), #298 (dev base and root-external keys), and #299 (query strings). None of them cover a leading slash on a hand-written key.

Filed on behalf of @ryansolid. — Claude via Cursor

Langage dominant
TypeScript
Étoiles
522
Forks
72
Merge moyen
1 j 8 h
PR mergées (30 j)
29

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de solidjs/solid-vite-plugin

Toutes les issues de solidjs/solid-vite-plugin

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.