VueCraft NPM

Image Kit ​

1.6.2 ​

2026-10-05

  • Fixed: with sources or a src object <VImage> renders a <picture>, and the class, style and other attributes given to the component went onto the <picture> instead of the <img> that shows the image — so border-radius, object-fit and similar rules from the user's own class had no visible effect, while the same class on a plain <img> worked. Attributes now always land on the element that shows the image: the placeholder, the error box or the <img>, also inside a <picture>. The <picture> itself is rendered with display: contents, so it takes no part in the layout and the <img> lays out as if it stood alone. Event listeners given to <VImage> (@click, …) are bound to the <img> too and work next to the component's own load/error handling. If a stylesheet or a test targeted the <picture> through a class or data-* attribute set on <VImage>, target the <img> or a parent element instead. See Layout without a wrapper.

1.6.1 ​

2026-10-05

  • Fixed: since 1.6.0 <VImage> rendered a fragment on the server, so the class, style and other attributes given to it were not applied to the <img>, and Vue warned Extraneous non-props attributes (class) were passed to component but could not be automatically inherited because component renders fragment or text or teleport root nodes. A fragment is now rendered only for the one case that needs it — a lazy image with ssrPlaceholder and a ready preview — and there the attributes are passed to the <img> explicitly. Every other server and client state is a single element again.
  • Fixed: the class is also put on the image inside the <noscript> fallback of a deferred image, so it is laid out the same without JavaScript.

1.6.0 ​

2026-10-03

  • Automatic placeholders for imported images. placeholders: { imports: true } (in Nuxt: vueImageKit: { placeholders: { imports: true } }) computes a placeholder at build time for every image a script or single-file component imports with a default import — including the imports Vue generates from src="…" in a template and the ones import.meta.glob(…, { eager: true }) expands to. No ?placeholder query and no template edits: the placeholder is registered under the imported value itself (the dev URL or the hashed build URL), so <VImage :src="hero" /> finds its blur and size on its own, in dev, in the build and during server rendering. mode, extensions and exclude tune it. See A placeholder for every imported image.
  • New export registerPlaceholder(src, data). VImage, v-lazy-img and useBackgroundImage() look a src up in that registry after the placeholders manifest, so no manifest has to be provided.
  • A corrupt raster image no longer fails the build when its placeholder is computed through the rewritten imports: it logs a warning and gets none.
  • New <VImage> prop ssrPlaceholder (opt-in, default false). The server-rendered <img> gets a ready preview (a data: URL from placeholder, image.placeholder or the registry) as its CSS background, so the picture has a blur before any JavaScript runs; without the prop nothing changes. A lazy image is also held back: the server sends a transparent pixel instead of the real src and puts the real <img> into a <noscript>, so the heavy file is only downloaded when the image nears the viewport, while crawlers and visitors without JavaScript still get it (an eager image — lazy="false" or priority — keeps its src). The preview keeps showing under the image after hydration, and server and client render the same output, so there is no hydration mismatch. See Preview in the server-rendered HTML.
  • New option placeholders.imports.preview (true, or a list of path patterns: a directory, an exact file, a part of a path or a glob such as src/**/hero-*.webp, compared with the file's real path from the project root, so aliased imports work). exclude takes the same patterns. See Choosing images by path. The plugin also renders a ready preview for the imported images and registers it, so <VImage :src="hero" ssr-placeholder /> is all a template needs. Off by default; needs the thumbhash package at build time. See A ready preview for server rendering.
  • The registry entries and registerPlaceholder() accept a ready preview (placeholder or preview). The registry lives in globalThis, so the server and the client copy of the package share it.