vite-config: dts extension rewrite mangles directory-barrel imports ('../utils' → '../utils.js' instead of '../utils/index.js')
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 72/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Tranquilla
- Stack tecnologico
- typescript, vite
- Ambito
- build-system
Direzione di ricerca
Inizia in packages/vite-config/src/index.ts, su ensureImportFileExtension e sulla relativa gestione di beforeWriteFile. Riproduci il problema con un barrel di directory e ispeziona i file .d.ts emessi per entrambi i rami ESM e CJS. Il lavoro è completato quando gli import da directory diventano ../utils/index.js o ../utils/index.cjs, mentre gli import da file normali rimangono invariati, e il problema di risoluzione dei tipi segnalato viene risolto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- TypeScript
- Stelle
- 397
- Fork
- 41
- Merge medio
- 1h 9m
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
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 TanStack/config
-
Svelte ESLint SupportAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
-
Dependency DashboardForse di nuovo libera @lachlancollins l’ha presa 828 giorni fa e non c’è nessuna pull request aperta. Apertadependencies
Tutte le issue di TanStack/config
Issue simili
-
fix(frontend): correct VITE_IS_DEVELPOMENT typo in shared/app.ts and align dev environment flagsAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
vicharanashala/ajrasakha#1439 ·
I maintainer di solito rispondono entro 1 giorno
-
Add: TV5Monde AsieApertaapproved check:passed streams:add
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
backnotprop/plannotator#1932 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 62/100
ibm-granite/granite.build#504 ·
I maintainer di solito rispondono entro 2 giorni
-
reproduced
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
anomalyco/opencode#55676 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno