Repository navigation
[Bug Report][3.12.7] Importing createVuetify adds about 520 MB TypeScript RSS #23005
Description
Environment
- Vuetify: 3.12.7
- Vue: 3.5.35
- TypeScript: 6.0.3
- Node: 24.18.0
- pnpm: 9.15.4
- OS: macOS arm64
Reproduction
Minimal reproduction: https://gist.github.com/hhochart/5980e81e4938d30c13550474457560a1
pnpm install
/usr/bin/time -l pnpm profile:plain
/usr/bin/time -l pnpm profile:vuetifyThe plain case contains one two-line TypeScript file. The Vuetify case only adds:
import { createVuetify } from 'vuetify'
export const plugin = createVuetify()Both projects use skipLibCheck: true and noEmit: true.
Actual behavior
| Metric | Plain TypeScript | Importing createVuetify |
|---|---|---|
| Files | 52 | 443 |
| Declaration lines | 0 | 262,188 |
| TypeScript reported memory | 61,730 KB | 548,208 KB |
| Peak RSS | 151,961,600 bytes | 671,858,688 bytes |
A single createVuetify import therefore adds roughly 520 MB peak RSS before any application or Vue SFC template type-checking is involved.
In a Vue monorepo using Volar, each configured application project pays this fixed cost. Three simultaneously open apps pushed the semantic tsserver above its default 3 GB heap and caused repeated FatalProcessOutOfMemory aborts.
The declaration expansion appears to come from lib/framework.d.ts: its GlobalComponents augmentation references every component through typeof import('vuetify/components'), and the vuetify/components barrel re-exports the complete component catalog. skipLibCheck avoids checking these declarations but TypeScript still parses and binds them.
Expected behavior
Importing the Vuetify plugin should not require TypeScript to load the declarations for every component. Ideally the framework/global-component typing could be split or made opt-in so applications using automatic imports only load declarations for components they actually use.
Additional measurement
In the real project, a shared style package containing 395 TypeScript lines peaked at 832 MB. Replacing only Vuetify's declarations with a stub reduced the same check to 279 MB. A full Vue application loaded 426 Vuetify declaration files totaling about 239k physical declaration lines.
Activity
J-Sek commentedon Jul 13, 2026
I cannot point to the source, but TS is more efficient if it gets everything in one large *.d.ts file instead of 100+ smaller ones. Not sure about the Go version though.
Either way, VSCode blows out ~2.5GB even without Vuetify, and while I can't say it is nice to force fellow developers into buying 16GB of RAM in the age of memory shortage and peak corporate greed, it was also normal for many years now.
This issue will depend on community effort to resolve and verify.
musatoktas commentedon Oct 12, 2026
I measured what one
import { createVuetify } from "vuetify"costs in a project with a single file, per release. TypeScript 5.9.3, vue 3.5.43,tsc --extendedDiagnostics, Linux CI, two runs per version (source: https://github.com/musatoktas/oss-olcum/actions/runs/38269714305). Check time is 0.01 s everywhere, so the cost is in the program, not in the check:The jump is between 3.7.19 and 3.8.12. I did not check which change caused it; I only have the two endpoints.
For 4.2.4 I also tried one experiment (https://github.com/musatoktas/oss-olcum/actions/runs/38270112043): I replaced the
GlobalComponentsblock inlib/framework.d.tswith an empty interface. In that run, Files went from 480 to 111 and Memory used from 534,011K to 101,701K. This is an upper-bound measurement, not a fix: it removes the global component types, so Volar's component types break.whyts 0.8.4 (https://github.com/musatoktas/whyts) now reports this case: it names
lib/framework.d.tsand its 218typeof import()references as the source of 409 of the 421 dependency files.J-Sek commentedon Oct 13, 2026
Can anyone verify claims from #23266?
musatoktas commentedon Oct 13, 2026
I measured #23266 against its base, since the question was whether the numbers hold.
Both sides were built from source with the full
pnpm buildon Linux CI (base:devat c5ce339, PR: 312b095), packed withpnpm pack, and installed into an empty project with TypeScript 5.9.3 and vue 3.5.x. The project has one file,import { createVuetify } from "vuetify"(c) orimport { VSelect } from "vuetify/components"(s).tsc --extendedDiagnostics, 3 runs per side, interleaved:createVuetify()VSelectSo the reduction in the PR description holds in this setup, about 68% less memory and 62% less total time for
createVuetify().whyts comparewith 10 runs per side agrees: total time median 3.895 s against 1.47 s, the ranges do not overlap. Check time is 0.01 s on both sides.Where it comes from: the file count goes up (518 to 553), but the source the compiler reads for
node_modulesgoes from 14.8 MB to 3.9 MB (framework.d.ts141 KB to 59 KB, the vuetify package 12.7 MB to 1 MB), and parse plus bind drop from 2.35 s to 1.18 s. Thetypeof import('vuetify/components')references are still there, so the program still loads the component catalog. It is much cheaper to load.Limits: one environment (Linux CI runner, TypeScript 5.9.3, Node 24), three
tscruns and tencompareruns per side. I did not check that the emitted types behave the same for users, and I did not measure tsserver or Volar memory in an editor. The two sides check different sets of files.Runs: https://github.com/musatoktas/oss-olcum/actions/runs/38380267485 (artifact
vuetify-23266).