Skip to content
vite-plugin-lit

All versions since 0.17.0

All versions

0.17.0

The Components tab now explains a component and lets you change it. Its details pane shows the documentation from your JSDoc or a Custom Elements Manifest, in the panel, in Lit Inspector and to agents. Primitive props, also inside objects, arrays and Maps, can be edited in place, held as overrides against the app’s own writes, and pinned to survive a reload. Anatomy labels sit beside the component with leader lines, and a CSS example shows each way of styling a shadow root. Nothing needs action to upgrade.

Watch it on YouTube

Added

  • The Components tab shows a component’s documentation. The details pane adds the selected element’s description, @examples, the events it fires, the CSS custom properties it reads and what each property is for, rendered as formatted text with long descriptions folded behind “more”. During dev it reads your components’ JSDoc straight from source; otherwise it uses a Custom Elements Manifest, from your project or a library such as Web Awesome. Hovering a documented slot or part in the Anatomy rows says what it is for, and the icon in the About heading tells where the docs came from.
  • Edit a component’s props from the details pane. A string, number or boolean gets an edit button, also inside an expanded object, array or Map; double-click a value to edit it, or a boolean to flip it. The value goes to the live element and lasts until the page reloads.
  • Overrides you can switch off, undo and pin. An edited value holds against the app’s own writes, with a checkbox to switch it off and see the app’s latest value and a button to remove it; a bar lists every override on the page and switches off or clears them all. Pin one and it comes back after a reload from the component’s first render, kept per tab and page path. In the browser extension pins live in the extension’s storage, never the site’s, and are cleared when the browser closes.
  • Lit Inspector shows component documentation. On a page that links its Custom Elements Manifests with <link rel="custom-elements-manifest">, the Lit tab shows each component’s docs. With DevTools on, pages from the dev server link the manifests your project and its dependencies ship, so this works there too.
  • Agents can read a component’s documentation. The new lit_component-docs MCP tool returns a tag’s description, examples, events, slots, CSS parts and custom properties, from source or a Custom Elements Manifest.
  • Hover a slot or part to find it on the page. Hovering a slot or CSS part row in the details pane outlines that region on the page, even with the Anatomy overlay off.
  • A CSS example with real UnoCSS utilities. One card per way of delivering CSS to a shadow root (a shared ?css-sheet, ?hmr-url, ?inline and a css literal through Lightning CSS), each counting its renders so an edit shows what restyles in place. UnoCSS reaches every component as one shared sheet.

Changed

  • Anatomy labels sit beside the component with lines to their regions. The overlay’s labels no longer pile up or drift off on small elements: they line up next to the component, never overlap, and a line leads from each to its slot or part. Repeated part names share one label.

Fixed

  • Custom timeline events line up with Lit’s. addTimelineEvent takes a performance.now() time, or none to stamp the event as it is added, and places it on the recording’s clock, so a router or store event no longer lands long after the updates it caused.
  • The selected component stays selected after a reload. Reloading the page no longer leaves the details pane showing some other component.
  • Collapsed Timeline rows say what changed. Each update’s row in the list names the reactive properties it changed again, as it did before rows were grouped, without having to open it.
  • Details sections fold again. Clicking a section heading in the Components tab hides its rows instead of only turning the caret.
  • Source paths wrap between folders. The defined and rendered links in the details header no longer split a file name in the middle when the pane is narrow.
  • Tooltips follow the keyboard. Tabbing between controls in the panel shows each one’s tooltip, not only the first one focused.

0.17.1

A small patch: Lit Inspector is now on Firefox Add-ons, and the Timeline list no longer jumps back to the newest event while you read further up. Nothing needs action to upgrade.

Added

  • Lit Inspector is on Firefox Add-ons. Install it with Add to Firefox from addons.mozilla.org and Firefox keeps it up to date, instead of loading a temporary add-on from a release after every restart.

Fixed

  • The Timeline list stays where you scrolled it. New events no longer pull the list back to the newest row while you read further up, open an update or follow an #event= link; at the end of the list it still follows them, now all the way to the last row.

0.18.0

Shared stylesheets now work with utility frameworks: UnoCSS utilities become one adopted sheet through unoSheet(), and Tailwind v4 classes you add in dev reach a ?css-sheet with their shadows, rings and gradients intact. Builds got leaner: vite build no longer loads the dev tooling, and what the CSS queries emit carries no HMR code. The Components tab gains a Request update button, and the console gets $lit and Store as global variable. Nothing needs action to upgrade.

Added

  • UnoCSS utilities can be one shared sheet across shadow roots. unoSheet() from @oddsquad/vite-plugin-lit/uno writes the utilities your source uses to a .css file; import it with ?css-sheet and every component adopts the same CSSStyleSheet, swapped in place when a new class shows up.
  • A Tailwind example. Three components share Tailwind v4 utilities as one adopted sheet, each counting its renders: change the brand colour and everything recolours in place, add a class and the shared sheet gains it, with shadows, rings and gradients working inside shadow roots.
  • Production builds can leave the dev tooling out entirely. Use litCss() from @oddsquad/vite-plugin-lit/build for vite build and HMR, the source overlay and DevTools are never imported into the build; it keeps the CSS queries, css literal minification and cssSheetBuild.
  • Request update from the Components tab. A button beside the tag name calls requestUpdate() on the selected element, and the Updates and Timeline tabs name the DevTools as that update’s cause.
  • $lit in the console is the selected component. Like $0 in Elements, it returns the element selected in the Components tab, in every host, so you can call its methods or read its fields directly.
  • Store a property as a global variable. A button on each Properties, State and Instance row puts the live value in temp1, temp2… on the page and logs it in the console, so you can work with the object itself instead of its preview.

Changed

  • Builds carry no dev code, with no config change. With plain litPlugin(), vite build no longer imports HMR, the source overlay or the DevTools panel, and a ?css-sheet or ?hmr-url import compiles without the hot-swap callback and the dev-server fetch rewrite. urlSheet() and devCacheBust() fold their dev branches away when minified.
  • Edits and overrides show up as the update’s cause. Updates you cause by editing or overriding a property in the Components tab now read “after edit in DevTools” or “after override in DevTools” in the Updates and Timeline tabs, instead of having no cause.
  • ?css-sheet on virtual:uno.css now tells you what to do instead. Importing a virtual CSS module with ?css-sheet or ?hmr-url warns that there is no file behind it and points to unoSheet(), instead of failing later with an error that doesn’t mention the query.

Fixed

  • @property rules in a ?css-sheet now apply inside shadow roots. Browsers ignore @property in a shadow root, so properties a shared sheet registered had no initial value there, and utilities built on them (Tailwind’s shadows, rings, transforms and gradients) rendered nothing. The plugin now registers them on the document as well, and a build only ships that code for sheets that have such a rule.
  • Tailwind classes you add in dev reach the shared ?css-sheet. A class written in a component now lands in the sheet every adopter shares and swaps in place; before, only edits to the CSS file itself did. In dev the sheet is built from the file’s ?inline text, so it no longer waits on a fetch either.
  • Component docs stay current. Changing a component’s JSDoc updates its About, property and event descriptions on the next hot patch, and a Custom Elements Manifest an analyzer rewrites shows up within a second or so, both without selecting another tag and coming back.
  • Sites that enforce Trusted Types keep working with the extension on. On a page whose CSP allows only Lit’s own lit-html policy, enabling Lit Inspector stopped the page’s components from rendering. The injected runtime no longer creates that policy, and its picker no longer needs one.
  • Rendered at links into index.html open the right line. In Chrome’s extension, an element written in index.html now opens that file at its line in the Sources panel, instead of Vite’s inline-script module at the top.
  • SVG files on an enabled site open cleanly. Viewing an .svg file directly on a site where Lit Inspector is on no longer logs a configure is not a function error.
  • Unminified builds no longer print your project’s absolute path. With build.minify: false, a ?css-sheet or ?hmr-url import’s region comment named the css file by its full path on disk; it now names it relative to the project root.

0.19.0

Lit rendered on the server with @lit-labs/ssr now works with the plugin: edits hot-patch hydrated components and reach the next server render, shared sheets arrive styled, and the Components tab shows where hydration stands. A new SSR example covers dev, production builds and StackBlitz. Lit Inspector gains a Lit tab in the Elements panel and reads Custom Elements Manifests from more places, and the DevTools flag double renders. Nothing needs action to upgrade.

Added

  • Server-rendered Lit works in the dev server. With @lit-labs/ssr in your Vite server, an edit patches hydrated components in place and the next server render uses the new code instead of failing because the tag is already defined. A ?css-sheet renders into the declarative shadow root, so the page arrives styled, and its edits restyle hydrated components. A defer-hydration component edited before it wakes renders the new template, and a page whose HTML predates an edit renders that component once in the browser instead of failing to hydrate. The new SSR guide shows the setup, and Troubleshooting covers the dock’s socket in middleware mode.
  • The Components tab shows hydration state. A server-rendered component is marked deferred while defer-hydration holds it back, not hydrated until its first update, and SSR the moment it hydrates, in the tree and the details pane.
  • An SSR example, on StackBlitz too. Open it from the README or the docs’ Demos page: the counter arrives as server HTML, hydrates, and keeps its count through an edit, with the DevTools dock connected.
  • Server-rendered pages in production builds, with the Lit panel. The SSR guide and example cover a production build served without Vite: shared ?css-sheet styles arrive inlined, and the Lit panel attaches through lit-devtools dev with each element’s hydration state.
  • The Lit panel works without Vite DevTools. With timeline: true and no DevTools(), the dev server serves the panel at /__lit/ and prints its address, instead of only warning that the panel never mounted.
  • A Lit tab in the Elements panel. The browser extension adds a Lit tab to the Elements sidebar, beside Styles and Computed, showing the properties, state, slots, parts and source links of the Lit element you select there.
  • Double renders are flagged. An update that a component’s own previous update scheduled, usually because updated() set a property, is marked re-rendered in the Updates tab and 2× in the Timeline list, and lit_update-summary reports it as selfCaused. The Components tab’s Warnings count how many times the recording shows an element re-rendering itself, also under a production build.
  • The Components tab counts dispatched events. With the Custom events layer on, a Dispatched section lists how many times the selected element dispatched each event type during the recording.
  • Properties show which class declared them. For a component that extends a base class or uses mixins, the Properties and State tables group their rows under the declaring class, the element’s own first.
  • Component docs include members from your mixins. For a component written as extends Sized(Base), the Components tab lists what your project’s Sized mixin adds, marked as inherited from it, and still reaches Base past a package mixin such as SignalWatcher.
  • Agents can set component properties. The new lit_set-prop tool sets a reactive property, or a field inside the object it holds, on a live element and answers with the element’s details afterwards. Agent edits land as overrides in the panel, where you can switch them off or clear them.
  • Lit Inspector can pause on an update or a property change. Arm update or render on the selected element, or the pause toggle on one of its properties, and the page stops in the debugger when it happens.
  • Lit Inspector finds more Custom Elements Manifests. When a page links none, the Lit tab looks for every custom-elements.json beside the page’s scripts and offers them, so Web Awesome’s docs show component documentation with one click. Manifests on another site, such as a CDN, work once Chrome is granted access to it, through an Allow access button for a linked one.
  • Choose the manifests Lit Inspector reads. The Settings tab’s Component docs section lists the page’s linked manifests, the ones found and the ones you add by URL, such as /dist/custom-elements.json. Each can be switched off, ignored and reset, or moved up and down; the first switched-on one that describes a component supplies its docs.
  • The extension shows where an element is rendered. On a page without the Vite plugin, the details pane’s rendered row names the template tag that created an element, found by the template’s text in the page’s sources, and in Chrome a click opens it in the Sources panel.
  • Read component docs without hovering. Turn on “inline descriptions” under Components in the Settings tab, and every documented property, attribute, slot and part shows its description under its row.
  • unoSheet() works with presetWind4. Pass preflights: true to keep Wind4’s theme variables and @property rules in the shared sheet; drop the reset at the preset with presetWind4({preflights: {reset: false}}).
  • Context consumers waiting for a provider say so. A subscribing consumer that no provider has answered yet reads “waiting for a provider” instead of linking to a provider that never answered it, and links as soon as a ContextRoot replays its request.

Changed

  • The Settings tab no longer lists env var names. Hints name the plugin option alone, the reset button reads “Reset overrides”, and a value set from the environment still shows its “(env)” badge.

Fixed

  • Hiding the panel clears what it drew on the page. Collapsing the dock, closing DevTools with the browser extension, or closing a panel opened as its own tab now takes down the anatomy overlay, hover outline and breakpoints and stops Live, instead of leaving them until the page reloads. The overlay comes back when the dock opens again.
  • Slotted context consumers link to the right provider. A consumer slotted into a component whose shadow tree provides the context now links to that provider, instead of to none or to one further out.
  • A provider’s details follow a value set directly. Setting a context provider’s value with setValue, without its host updating, refreshes the selected provider’s row right away instead of on its next update.
  • A component whose constructor threw is no longer called “not Lit”. The Components tab marks it not upgraded and says its constructor probably threw, instead of claiming another library defined it.
  • The Anatomy “not rendered” list follows the page. A light child added with a slot name the element doesn’t have, or renamed to one, shows up without reselecting the element.
  • The Updates tab’s equal-content badge shows its icon again. The badge that flags a property changed to a new reference with equal content rendered as a bare number.
  • lit-devtools mcp finds dev servers behind your own HTTP server. When Vite runs in middleware mode with your server passed in, the plugin registers that server’s real port instead of probing 5173 and warning that discovery is unavailable.

0.20.0

The plugin now runs in Astro. lit() server-renders and hydrates Lit components with no other renderer, and litDevtools() brings hot patching and the Lit panel, opened from Astro’s dev toolbar. The Components tab reads hydration as a state and stops labelling other libraries’ elements. The DevTools now warn when the Lit Inspector extension and the plugin share a page, and both work there. Nothing needs action to upgrade.

Added

  • The plugin runs in Astro, with the Lit panel in the dev toolbar. Add litDevtools() from @oddsquad/vite-plugin-lit/astro to your integrations: Lit components hot-patch in place, hydrated or not, and the Lit logo in Astro’s dev toolbar opens the panel on the page you are on. LIT_PLUGIN_TIMELINE=false turns the panel off, and the timeline option wins over it.
  • Lit components render and hydrate in Astro with no other renderer. lit() from @oddsquad/vite-plugin-lit/astro server-renders Lit components, hydrates them with their array and object props, keeps a defer-hydration you wrote until you remove it, and needs no hydrate imports in your pages. Components nested in another’s shadow root hydrate after a view transition too.
  • Resize the Lit window in Astro’s dev toolbar. Drag the grip in its top corner to make it bigger or smaller; the size sticks across page loads, and a double click on the grip resets it. The window lines up with where the toolbar is docked.
  • The DevTools warn when two runtimes share a page. With the Lit Inspector extension enabled on a dev server that already runs the plugin, the console and the Components tab now say that two runtimes are loaded and that the extension should be off for that site, instead of the picker silently doing nothing.

Changed

  • Hydration state reads as a state. A server-rendered component that has hydrated is now marked hydrated instead of SSR, and deferred, not hydrated and hydrated show as pills in the Components tree and details, with a drop icon that is empty until the element hydrates and filled once it has.
  • Custom elements from other libraries sit in the tree unmarked. The muted not Lit chip is gone from their rows and the details head, so wrappers like Astro’s islands no longer crowd the tree with labels; the details pane still says why they have no properties.
  • A component that never upgraded shows one chip, not two. One the server rendered was marked both not upgraded and not hydrated, as if hydration were still coming; it now carries only not upgraded, whose tooltip says it still shows the HTML the server sent.

Fixed

  • The Lit Inspector extension works on a dev server that runs the plugin. Enabled for such a site, Pick did nothing and threw in the console, and Vite DevTools lost the page. The extension’s runtime now serves the page and the plugin’s shares it, so both panels show the tree and Pick works from either.
  • The link printed with the DevTools code opens the Lit panel. Without the Vite DevTools hub, the #devframe_otp link in the terminal opened your app instead of the panel at /__lit/, so you had to type the code; it now opens the panel, approved.
  • The Lit panel connects on StackBlitz without Vite DevTools. In a WebContainer the panel the plugin serves at /__lit/ used to be refused by its own socket and never show the page; it now admits StackBlitz’s origins.

0.20.1

A patch of fixes: the Lit tab in Firefox DevTools works again after opening blank since 0.19.0, server-rendered elements hydrate with the source overlay on, and closing a panel tab always clears what it drew. Nothing needs action to upgrade.

Fixed

  • The Lit tab works in Firefox DevTools again. Since 0.19.0 it opened blank in Firefox; it now shows the site’s status and the inspector once the site is enabled.
  • Server-rendered Lit elements hydrate with the source overlay on. An element whose template renders another custom element no longer re-renders in the browser with a warning about an edit that never happened, in Astro or any other server rendering.
  • Closing a panel tab always clears what it drew on the page. The anatomy overlay, outline and Live mode no longer outlive a panel tab that closed too fast to say so, or crashed.
  • The panel stops filling the console with warnings. Opening it no longer prints Web Awesome’s size="small" is deprecated warnings, and a panel in a tab of its own, at /__lit/ or in Firefox’s DevTools, no longer warns that the in-page channel has no handshake targets.

0.21.0 Latest

Lit Inspector now opens sources in your editor: on a page a Vite dev server serves, even without the plugin, a component’s defined and rendered links open the file. Locations read shorter everywhere, by package and version or relative to the project, and a library’s component names the module its manifest gives. The panel also follows sites that swap in a new page body, such as webawesome.com. Nothing needs action to upgrade.

Added

  • The extension opens sources in your editor on a Vite dev server. On a page Vite serves, with or without the plugin, the defined and rendered links open the file in your editor instead of only in Chrome’s Sources panel, and work in Firefox too. They use the plugin’s endpoint when it serves one, else Vite’s own /__open-in-editor, under the page’s base. When the extension can’t tell where the project is on disk, the bottom of the Lit tab says so and offers Set project folder… for the site.

Changed

  • Locations in dependencies name the package. A component from a package reads as its name, version and path inside it, such as @awesome.me/webawesome 3.14.0 › dist/chunks/chunk.js:11, instead of five lines of pnpm store path; the full path is in the tooltip.
  • A package’s component names its module. When the package ships a Custom Elements Manifest, defined reads as the module and class it names, such as components/card/card.js (WaCard), instead of a bundler chunk. That holds in the Vite panel and, for a manifest read from the site, in the extension.
  • Project files read relative to the project. A location given as an absolute path, such as Astro’s for an element in .astro markup, reads src/pages/basics.astro:26, in the Vite panel and in the extension on a Vite dev server; the full path is in the tooltip.

Fixed

  • The panel follows sites that swap in a new page body. On a site that navigates with Turbo Drive, such as webawesome.com, the Components tree updates as you follow links, and the hover outline, update flashes and element picker keep working.
  • Lit components with a closed shadow root show their children. The Components tree lists what such a component renders, and Live follows changes inside it, as the anatomy view already did.
  • Elements written in .astro markup show where they are rendered. The rendered link, the source overlay and timeline events now point at the .astro file and line, where before those elements had no location at all.
  • The extension finds a decorated component on a Vite dev server. On a page Vite serves without the plugin, defined pointed at the compiler’s decorate helper instead of the file that declares the class.