vite-config: dts extension rewrite mangles directory-barrel imports ('../utils' → '../utils.js' instead of '../utils/index.js')
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 72/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Tranquilo
- Stack tecnológico
- typescript, vite
- Área
- build-system
Línea de trabajo
Comienza en packages/vite-config/src/index.ts, en ensureImportFileExtension y su manejo de beforeWriteFile. Reproduce el problema con un barrel de directorio e inspecciona los archivos .d.ts generados para ambas ramas ESM y CJS. Se considera terminado cuando las importaciones de directorios se conviertan en ../utils/index.js o ../utils/index.cjs, mientras que las importaciones de archivos normales permanezcan sin cambios, y se resuelva el fallo de resolución de tipos informado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
tanstackViteConfig's declaration post-processing (ensureImportFileExtension in packages/vite-config/src/index.ts) appends .js / .cjs to every extensionless relative specifier in emitted .d.ts files, without checking whether the specifier targets a directory barrel.
Given a source file that imports from a directory with an index.ts:
// src/adapters/image.ts
import type { GeminiClientConfig } from '../utils' // src/utils/index.ts
the emitted declaration becomes:
// dist/esm/adapters/image.d.ts
import { GeminiClientConfig } from '../utils.js';
but the build only emits dist/esm/utils/index.d.ts — there is no dist/esm/utils.d.ts — so the specifier should have been '../utils/index.js'. Any consumer compiling with skipLibCheck: false fails with:
error TS2307: Cannot find module '../utils.js' or its corresponding type declarations.
The emitted JS is unaffected (rollup/rolldown resolves the barrel itself, pointing at the concrete module, e.g. '../utils/client.js'), so this is invisible at runtime and only breaks the type layer.
Both the ESM (.js) and CJS (.cjs) branches of ensureImportFileExtension have the same problem. Verified present in 0.4.1 and still present in the 0.5.2 source.
Why it goes unnoticed
- The rewrite happens in
beforeWriteFile, after type-checking —afterDiagnosticvalidates the source compile, and the rewritten output text is never re-checked. - Consumers overwhelmingly use
skipLibCheck: true, which suppresses TS2307 inside.d.tsfiles; the affected types silently degrade instead of erroring. publintdoesn't catch it (it checks the export map, not deep declaration resolution).@arethetypeswrong/clidoes flag it, asInternalResolutionError.
Real-world occurrence
Published packages built with this config ship the broken specifiers today, e.g. @tanstack/[email protected]:
dist/esm/adapters/image.d.ts→import { GeminiClientConfig } from '../utils.js'(onlydist/esm/utils/index.d.tsexists)
and @tanstack/ai (dist/esm/activities/generate*/index.d.ts → '../middleware.js', where middleware is a directory barrel).
Steps to reproduce
- Scaffold a lib using
tanstackViteConfigwithsrcDir: './src', entry./src/index.ts. - Add
src/utils/index.tsexporting anything, and import it from a sibling asfrom '../utils'. vite build, then inspect the emitted.d.ts— the specifier is'../utils.js'.- Compile a file importing the package with
skipLibCheck: false→ TS2307.
Suggested fix
Make the rewrite resolution-aware instead of purely textual. beforeWriteFile receives the output filePath, and the dist tree mirrors entryRoot/srcDir, so for each relative specifier the plugin can check whether the target resolves to a directory (or equivalently, whether <target>/index.d.ts rather than <target>.d.ts is being emitted) and append /index.js in that case:
'../utils' → '../utils/index.js' // when utils/ is a directory barrel
'../client' → '../client.js' // unchanged for plain files
Happy to send a PR if the approach sounds right.
- Lenguaje dominante
- TypeScript
- Estrellas
- 397
- Forks
- 41
- Merge medio
- 1 h 9 min
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
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 TanStack/config
-
Svelte ESLint SupportAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 45/100
-
Dependency DashboardQuizá libre de nuevo @lachlancollins la tomó hace 823 días y no hay ningún pull request abierto. Abiertodependencies
Todos los issues de TanStack/config
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
supadata-ai/mcp#27 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
capricorn86/happy-dom#2485 ·
Los mantenedores suelen responder en 2 días
-
优化导入 OCR 模型选择文件的按钮样式Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
siyuan-note/siyuan#20430 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Albert-Weasker/niubigeo#194 ·
Los mantenedores suelen responder en 1 día