vite-plugin: SSR function import path is wrong when Vite root is a subdirectory (relative build.outDir resolved against cwd)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 78/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript, vite
- Área
- build-system
Línea de trabajo
Comienza en dist/main.js, alrededor de la lógica de writeBundle que usa el entorno build.outDir, y luego ejecuta la reproducción indicada con pnpm run build desde la raíz del repositorio. Está terminado cuando web/.netlify/v1/functions/server.mjs usa el import relativo correcto y el bundling de Netlify Functions resuelve server.js para una raíz de Vite en un subdirectorio.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 1
- Forks
- 4
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de netlify/framework-adapters
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
netlify/framework-adapters#67 · 3 comentarios · 1 reacción ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
-
`@netlify/vite-plugin` fails to load under `TypeScript 7` via `ts-api-utils` `TypeFlags` accessAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
netlify/framework-adapters#65 · 1 comentario ·
-
framework-bump-failure
Dificultad 3/5 1-2 días Aptitud para principiantes 38/100
Todos los issues de netlify/framework-adapters
Issues similares
-
level/task type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
wazuh/wazuh-dashboard-plugins#9508 ·
Los mantenedores suelen responder en 1 día
-
Testnet EOL page links Zonescan mainnetPosiblemente ocupada @napelvs la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 76/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Azure-Samples/azure-search-openai-demo#3249 ·
Los mantenedores suelen responder en 1 día
-
[Docs] docs/architecture.mermaid leaves out 21 of the 51 src/ directoriesPosiblemente ocupada @uyg7x la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
enhancement status:needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
dongdongbh/Mindwtr#1438 ·
Los mantenedores suelen responder en 1 día