vite-plugin: SSR function import path is wrong when Vite root is a subdirectory (relative build.outDir resolved against cwd)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 78/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- typescript, vite
- Ambito
- build-system
Direzione di ricerca
Inizia in dist/main.js, intorno alla logica di writeBundle che usa l’ambiente build.outDir, quindi esegui la riproduzione segnalata con pnpm run build dalla root del repository. È completato quando web/.netlify/v1/functions/server.mjs usa l’import relativo corretto e il bundling di Netlify Functions risolve server.js per una root Vite in una sottodirectory.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Environment
@netlify/vite-plugin-tanstack-start1.3.19 (bundles@netlify/vite-plugin3.0.1)@tanstack/react-start1.168.54vite8.3.0- Node 24, pnpm
Summary
When the Vite root is a subdirectory of the repository and the build runs from the repository root, the generated SSR function gets an extra ../ in its import specifier.
# web/.netlify/v1/functions/server.mjs (generated)
import serverEntrypoint from "../../../../dist/server/server.js";
# expected
import serverEntrypoint from "../../../dist/server/server.js";
Netlify's Functions bundling then fails:
◈ Functions bundling
◈ Packaging Functions from web/.netlify/v1/functions directory:
- server.mjs
X [ERROR] Could not resolve "../../../../dist/server/server.js"
web/.netlify/v1/functions/server.mjs:1:29
This makes the SSR/API function undeployable for this layout. The same wrong specifier is produced regardless of whether the directory is discovered as a framework function (<base>/<package>/.netlify/v1/functions) or via [functions] directory.
How to reproduce
Repo layout where Vite root is a subdirectory but the build is invoked from the repo root:
repo/
├─ netlify.toml # [build] command = "pnpm run build"
├─ package.json # "build": "vite build --config web/vite.config.ts"
└─ web/
├─ vite.config.ts # root: <web/>
└─ src/...
web/vite.config.ts:
export default defineConfig({
root: rootDir, // web/
plugins: [tanstackStart(), netlify(), react()],
});
Then:
pnpm run build # from repo root, process.cwd() !== config.root
cat web/.netlify/v1/functions/server.mjs
Cause
@netlify/vite-plugin dist/main.js (build plugin):
async writeBundle(_, bundle) {
const functionsDirectory = join(resolvedConfig.root, NETLIFY_FUNCTIONS_DIR);
const serverEntrypoint = getServerEntrypoint(bundle, this.environment.config.build.outDir);
const serverEntrypointRelativePath = toPosixPath(relative(functionsDirectory, serverEntrypoint));
// ...
}
this.environment.config.build.outDir is a relative value here (dist/server): TanStack Start's plugin derives the per-environment output directory as join(userConfig.build?.outDir ?? 'dist', 'server') (@tanstack/start-plugin-core vite/output-directory.ts), so the environment config keeps it relative.
path.relative(from, to) resolves a relative to against process.cwd(). When process.cwd() !== config.root, the entry path resolves to <repo>/dist/server/server.js instead of <repo>/web/dist/server/server.js, producing one extra ../.
In a project where cwd === root this happens to work, which is why it only shows up with a subdirectory root.
Suggested fix
Resolve the output directory against the Vite root before computing the relative path:
const outDir = isAbsolute(this.environment.config.build.outDir)
? this.environment.config.build.outDir
: resolve(resolvedConfig.root, this.environment.config.build.outDir);
const serverEntrypoint = getServerEntrypoint(bundle, outDir);
Workaround
Setting an absolute build.outDir in vite.config.ts avoids the issue:
build: { outDir: path.join(rootDir, "dist") }
but it would be good not to require that.
- Lingua principale
- TypeScript
- Stelle
- 1
- Fork
- 4
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di netlify/framework-adapters
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
netlify/framework-adapters#67 · 3 commenti · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
-
`@netlify/vite-plugin` fails to load under `TypeScript 7` via `ts-api-utils` `TypeFlags` accessAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
netlify/framework-adapters#65 · 1 commento ·
-
framework-bump-failure
Difficoltà 3/5 1-2 giorni Idoneità per principianti 38/100
Tutte le issue di netlify/framework-adapters
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
getsentry/sentry-conventions#732 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
status:in-linear status:team-assigned team:nodes
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
n8n-io/n8n#41548 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
motiondivision/motion#3955 ·
I maintainer di solito rispondono entro 1 giorno
-
DQ assisgnment closing at CRApertaenhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
equinor/prisma-decision-web#919 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 83/100