Library is importing the full svelte/compiler #201
Description
Came across this while working on improving my rendering times. AI could be wrong but wanted to report.
Importing VERSION from svelte/compiler bundles ~414KB of compiler code into client applications
src/config.ts imports VERSION from svelte/compiler:
import { VERSION as SVELTE_VERSION } from 'svelte/compiler';
https://github.com/cloudinary-community/svelte-cloudinary/blob/main/packages/svelte-cloudinary/src/config.ts#L2
This single import causes the entire Svelte compiler to be bundled into every client application that uses svelte-cloudinary. In Svelte 5, svelte/compiler includes:
acorn (JavaScript parser)
@sveltejs/acorn-typescript
esrap, magic-string, zimmerframe
All compilation/parsing logic
This adds ~414KB of dead code to client bundles. The VERSION string is the only thing used from the compiler — it's passed to Cloudinary's analytics as techVersion.
Impact
Per the official installation guide, svelte-cloudinary is installed as a devDependency in SvelteKit projects. Despite being a devDependency, Vite still resolves and bundles all of its imports into the client output. This means every app using , getCldImageUrl, or any other svelte-cloudinary export pays the ~414KB cost, since config.ts is imported transitively by all public APIs.
Suggested fix
Option A — Hardcode the major version at build time
The scripts/version.js build script already generates src/version.ts for the svelte-cloudinary version. A similar approach could resolve the Svelte version from svelte/package.json at build time and write it into a generated file, avoiding any runtime import of the compiler.
Option B — Read from svelte/package.json (Svelte 5 only)
Svelte 5's exports map includes "./package.json": "./package.json", so this works:
// @ts-expect-error — no type declarations for JSON import
import { version as SVELTE_VERSION } from 'svelte/package.json';
This is a few hundred bytes vs ~414KB. Note: Svelte 4's exports map does not expose ./package.json, so this would only work for Svelte 5+.
Option C — Import from svelte with a fallback
The svelte types declare export const VERSION: string, but the runtime entry points (src/index-client.js, src/index-server.js) do not actually re-export it today (see [sveltejs/svelte tracking issue]). A defensive approach:
import { VERSION as SVELTE_VERSION } from 'svelte';
function normaliseVersion(version: string) {
if (!version) return '0.0.0';
return version.includes('-') ? version.split('-')[0] : version;
}
This avoids the compiler import entirely. Analytics techVersion would show 0.0.0 until Svelte adds VERSION to its runtime exports (matching what the types already promise). Once Svelte ships that fix, this code would work correctly with no changes needed.
Environment
svelte-cloudinary v2.3.1
Svelte 5.x (issue also applies to Svelte 4, but bundle impact is smaller there since Svelte 4's compiler is lighter)
Vite / SvelteKit
Bundle analysis
Using vite-bundle-visualizer or similar tools, svelte/compiler appears as a large chunk in client bundles traced back to svelte-cloudinary/src/config.ts.