@svebcomponents/build Changelog

0.4.0

Minor Changes

• 86e6596: Infer custom elements directly from same-basename .svelte source files and build same-basename .ts/.js sources as ordinary modules. Mixed packages can ship helpers without running them through the custom-element pipeline.

  Migration

  Rename each component to match its declared JavaScript output. Given this export:

  {
    "exports": {
      ".": {
        "types": "./dist/client/ExampleComponent.d.ts",
        "default": "./dist/client/ExampleComponent.js"
      }
    }
  }

  use src/ExampleComponent.svelte as the source entry.

  When upgrading, delete any entry module that only exported the component. If the module also contains runtime logic or additional exports, keep it as an ordinary module or move to an explicit svebcomponents.config.ts.

  The source convention is strict:

  • <name>.svelte is a svebcomponent entry.
  • <name>.ts or <name>.js is an ordinary module entry.
  • More than one matching source is an error; use an explicit svebcomponents.config.ts for non-conventional layouts.

  For SSR preparation, place <name>.ssr.ts or <name>.ssr.js next to <name>.svelte.

  Direct component declarations are now generated from component analysis and include the module’s default custom-element constructor together with the element, attribute, event, and template types.

• a4e45b7: Emit a custom elements manifest and TypeScript types for the elements a package ships, so editors and consuming templates know the tags and what they accept.

  custom-elements.json (custom elements manifest 2.1.0) describes attributes, property-only members, events with their detail type, slots and CSS custom properties. The build points out the package.json wiring it needs (customElements, files) when that is missing.

  The TypeScript half is appended to the declaration file each entry already emits — the one its types condition points at — so import "my-components" is enough to type document.querySelector("my-el"). Per element it exports:

  • XElement — the DOM element, with a narrowed addEventListener
  • XAttributes — what markup may set, each attribute also accepting its string form
  • XEventHandlers — onname-style handler props for dispatched events
  • XEventMap — event name to CustomEvent<Detail>

  Svelte template types are registered automatically when the package declares svelte as a required dependency of its consumers (a dependency, or a peerDependency not marked optional). That gate matters: the augmentation imports from svelte/elements, and a package whose standalone build bundles Svelte may be consumed by an application with no svelte installed, which would then fail to resolve it under skipLibCheck: false.

  Vue and React augmentations are not generated. They have to name types from frameworks this package neither depends on nor tests against, and those conventions change between major versions, so a subtly wrong generated augmentation would be worse than a few lines the consumer controls. The docs’ Types section carries verified recipes built from the exported types.

  Property-only props (functions, snippets) appear on the element interface but never among the attributes: in a template onPick={fn} is event-handler syntax rather than a property assignment, so listing it there would type-check a handler that never runs. Dispatched custom events are exposed instead.

Patch Changes

• 86e6596: Resolve a source entry for exports whose target carries no file extension.

  exports may legally point at an extensionless path. Entry inference stripped the extension by slicing -extension.length off the end, which for an empty extension is slice(0, -0) — the empty string rather than the whole path. Every candidate source then collapsed to a bare extension, so inference failed even when the component was sitting right there, and reported it as:

  [svebcomponents]: could not find a source for ./dist/client/index.
    Expected exactly one of .svelte, .ts, or .js.

  Such an export now resolves against src/ like any other.

• e7267f8: Documentation pass across the package READMEs ahead of the beta launch.

  • @svebcomponents/ssr, ssr-vue, ssr-react and ssr-astro gained the install command they were missing.
  • @svebcomponents/build’s options table was missing hydratable, ssrEntryFileName and svelteConfig, and did not show how a package with several components composes defineConfig calls.
  • @svebcomponents/ssr’s package-author example used import without types where every other example in the docs uses default with them, and the enable-async opt-in for non-Svelte hosts was undocumented.
  • The three integration READMEs each restated the shared SSR layer’s behaviour — the Lit renderer registry, the server-side svelte requirement, the declarative shadow DOM contract, the definition of an asynchronous component. Each now links to the canonical explanation and keeps only what is specific to its framework.
  • Removed references to internal e2e/* directories, which readers cannot run, and normalised the product name to lowercase svebcomponents.

• e7267f8: Point the CLI and runtime messages at the documentation’s new URLs.

  The docs site moved its concept pages to paths that match how the sidebar is organised, so the two links printed from package code moved with them:

  • the manifest hint in @svebcomponents/build now points at /guides/build/#element-types--manifest
  • the slotted-component hydration notice in @svebcomponents/ssr now points at /server-rendering/hydration/#limitations

  The old paths are redirected, so messages printed by already-released versions keep resolving.

• 86e6596: Build .ts/.js module entries for the browser rather than for Node.

  An ordinary module export is written into dist/client/, beside the compiled components, and is loaded by browsers. Its tsdown config did not set platform, so it took tsdown’s default of "node" and resolved the node key of a dependency’s exports map — shipping a dependency’s Node build in a bundle served to the browser. Module entries now resolve the same conditions the component build does, including production, so esm-env-style dev branches are eliminated instead of surviving as runtime checks.

• 86e6596: Declare license, description and homepage, and ship the license text in the published tarball.

  Every package was published without a license field and without a license file of its own. npm only includes LICENSE* from the package directory, so the repository’s MIT license never reached consumers and automated license scanners had nothing to read. Each package now carries its own copy of LICENSE.md alongside "license": "MIT".

  description is what npm shows on the package page and in search results, and homepage now points at each package’s reference page on the documentation site.

• 86e6596: Stop corrupting literal types that spell one of a component’s local type names.

  Generated declarations prefix a component’s local types so several components can share one declaration file (Detail becomes Button$Detail). The rewrite matched names anywhere in the declaration’s source text, including inside string literals, so a literal type whose value happened to match a local type name was rewritten too:

  // source
  interface Detail {
    id: string;
  }
  type Mode = "Detail" | "summary";
  
  // generated, before
  type MyWidget$Mode = "MyWidget$Detail" | "summary";

  Consumers writing mode="Detail" — the value the element actually accepts — got a type error, while the bogus "MyWidget$Detail" type-checked and failed at runtime. Literals are now stepped over.

  Two adjacent defects went with it: names are matched in a single alternation, so a name introduced by an earlier rewrite can no longer be rewritten again; and names are escaped when built into the pattern, so a local type containing $ no longer silently fails to match.

• Updated dependencies [86e6596]

• Updated dependencies [86e6596]

• Updated dependencies [e7267f8]

• Updated dependencies [e7267f8]

• Updated dependencies [a4e45b7]

• Updated dependencies [86e6596]

  • @svebcomponents/auto-options@0.3.0
  • @svebcomponents/ssr@0.5.0

0.3.7

Patch Changes

• Updated dependencies [e858eca]
• Updated dependencies [ab7d1cd]
• Updated dependencies [567aef3]
• Updated dependencies [0d1077f]
  • @svebcomponents/ssr@0.4.0
  • @svebcomponents/auto-options@0.2.1

0.3.6

Patch Changes

• Updated dependencies [117c5ba]
  • @svebcomponents/ssr@0.3.3

0.3.5

Patch Changes

• 1ca557a: Update the build integrations for tsdown 0.22 while preserving the existing .js and .d.ts output contract.
• Updated dependencies [1ca557a]
  • @svebcomponents/ssr@0.3.2

0.3.4

Patch Changes

• 513dea0: Bundle the hydratable wrapper into a hydratable component’s client build, so the Svelte-bundled dist/client stays loadable straight from a URL.

  auto-options injects import { hydratable } from "@svebcomponents/ssr/hydration", and only its sibling @svebcomponents/ssr/hydration-host was forced non-external. A component that declares @svebcomponents/ssr as the optional peer dependency it is meant to be therefore shipped a bare specifier in an otherwise self-contained bundle — which a browser cannot resolve without an import map, so the custom element never registered. Resolving it via an import map would not have been a fix either: the module imports svelte, so it would pull a second Svelte runtime in alongside the one already bundled.

  Adds ~2 kB raw to dist/client for hydratable components, which is the cost of the bundle actually being self-contained.

0.3.3

Patch Changes

• 3b2e7c7: Resolve browser bundles against the production export condition, so Svelte’s dev-only code no longer ships to the browser.

  Without it, esm-env resolved DEV through its dev-fallback — a runtime process.env.NODE_ENV check rather than a literal — so no if (DEV) branch in Svelte’s runtime could be eliminated and the full dev-only error and warning message texts ended up in the published bundle. Cross-module const inlining is enabled alongside it, since rolldown otherwise emits the resolved DEV as a module-level var that the minifier will not fold into its use sites.

  The e2e basic component’s client bundle drops from 42.3 kB to 32.6 kB raw (15.9 kB to 12.7 kB gzipped).

0.3.2

Patch Changes

• Updated dependencies [821e5df]
  • @svebcomponents/ssr@0.3.1

0.3.1

Patch Changes

• d714a97: The client build of a hydratable component now bundles @svebcomponents/ssr’s HydrationHost (compiled by the component’s own toolchain, exactly like the server-side host) instead of leaving import ... from "@svebcomponents/ssr/hydration-host" as an external runtime import. That subpath ships as raw .svelte, so an external import resolved to an uncompiled .svelte at runtime — which a consuming app’s SSR could only load by adding every such component to ssr.noExternal. Bundling the host removes that raw-.svelte reason for a per-component entry; consumers also need an @svebcomponents/ssr version whose wrapper recognizes renderers across bundled and external module instances before removing the entry entirely. Hydration markers still match by construction because both the client and server host are compiled by the same (component author’s) build.

0.3.0

Minor Changes

• fe3e191: - The generated SSR renderer entry now self-registers with ElementRendererRegistry when the component’s tag name can be determined at build time (read from its defineElement("tag", Component) call, which every component entry point already makes). Consuming apps no longer need to import ElementRendererRegistry and call .set() by hand — a bare import "my-component-package/ssr" is enough. Falls back to today’s manual registration when the tag can’t be determined statically (e.g. a dynamically computed tag).

  • Components with an SSR build now get a runtime-guarded shim install (if (typeof window === "undefined") { await import("@svebcomponents/ssr/shim"); }) prepended ahead of all bundled client code, so a custom element’s compiled class can never evaluate before the shim installs — regardless of which import path reaches it first (a generated SSR entry’s controlled dynamic import, or a consuming app’s own static import needed for browser registration, which frameworks like SvelteKit compile into the server bundle too). Scoped to SSR-enabled components only: referencing the optional @svebcomponents/ssr peer at all, even behind a runtime check, makes dev-server tooling (Vite’s import analysis) try to resolve it — so browser-only components never get this guard and are unaffected.

• fe3e191: Components can now declare their custom element tag with Svelte’s own string-shorthand syntax, and never need a manual registration call:

  <svelte:options customElement="my-component" />

  @svebcomponents/auto-options expands this into the object form, merging in the inferred props (previously this form was rejected outright — <svelte:options customElement="tag-name"/> bailed with a warning and skipped prop inference entirely). The object form (customElement={{ tag: "..." }}) is unaffected.

  @svebcomponents/build’s browser build now guards Svelte’s own auto-generated customElements.define(...) call against being run more than once — the actual reason component entrypoints previously had to hand-write a guarded registration via @svebcomponents/utils’s defineElement. That’s no longer necessary: a package entrypoint can simply re-export its component, with no registration call at all. defineElement remains available as a manual escape hatch for tags that can’t be a literal in <svelte:options> (e.g. computed at build time).

  @svebcomponents/ssr’s generated SSR entry now reads a component’s tag from its <svelte:options customElement> declaration (via svelte/compiler’s normalized parse() output, which resolves both syntax forms identically) instead of regexing a defineElement(...) call out of the entry file — no behavior change for consumers, just a more direct source now that the tag no longer needs to live in a separate manual call.

Patch Changes

• Updated dependencies [7164bd3]
• Updated dependencies [fe3e191]
• Updated dependencies [fe3e191]
• Updated dependencies [6a8034f]
  • @svebcomponents/ssr@0.3.0
  • @svebcomponents/auto-options@0.2.0

0.2.1

Patch Changes

• db1bec7: Fix the CLI entry point on Windows by converting its absolute path to a file URL before importing it. Align tsdown with consumer installations through a peer dependency and make the defineConfig return type explicit so exported configs have portable declaration types.

0.2.0

Minor Changes

• bb1ca02: Add automatically discovered, server-only entry.ssr.ts preparation hooks for setting component properties before SSR and serializing the results for hydration.

Patch Changes

• Updated dependencies [bb1ca02]
  • @svebcomponents/ssr@0.2.0

0.1.0

Minor Changes

• c2f1b6c: Hydratable custom elements: server-rendered declarative shadow DOM is now hydrated instead of being wiped and re-rendered when the element upgrades.

  Previously, svelte’s generated custom element always called attachShadow (clearing the declarative shadow root per spec) and then mounted the component from scratch — losing the server-rendered DOM, transient state, and re-creating every node. Now, @svebcomponents/build compiles components as hydratable by default:

  • @svebcomponents/auto-options injects svelte’s official customElement.extend hook wired to the new hydratable wrapper from @svebcomponents/ssr/hydration.
  • The wrapper claims the declarative shadow root before svelte can clear it and hydrates it via svelte’s public hydrate() API — the server-rendered nodes are adopted in place, styles are deduped by svelte itself, and the component is fully reactive afterwards.
  • On the server, the generated SSR entry renders through a HydrationHost component (also used on the client) so the markup structure matches by construction.
  • Anything non-hydratable — no declarative shadow root, slotted components, reconnection after teardown — falls back to svelte’s untouched mount path, and svelte’s own hydration mismatch recovery re-mounts, so a failed hydration degrades to exactly the previous behavior.

  Opt out per package with defineConfig({ hydratable: false }) (or per component by declaring your own extend). Client custom-element bundles are now built with platform: "browser", so browser export conditions resolve correctly.

  Known limitations (fall back to mount): components with slots (expected to become hydratable with Svelte 6, when slots are no longer compiled through the legacy transformation — a dev-mode console.info makes the fallback visible); legacy createEventDispatcher events on hydrated elements (native $host() events are unaffected); component exports are not exposed on hydrated hosts. See the new Hydration docs for details.

Patch Changes

• 8bceff0: Fix a race that could corrupt build output when several components share an output directory (e.g. multiple components inferred from package.json exports writing to dist/client): component configs are built in parallel and tsdown’s default per-build clean deleted sibling builds’ output. The config factories now set clean: false and the svebcomponents CLI cleans each distinct output directory once before building.

• c2f1b6c: Declare vite, tsdown, and rolldown as optional peer dependencies of @svebcomponents/ssr.

  The ./vite and ./tsdown entries type against these packages, but they were only devDependencies — under pnpm’s isolated layout a consumer’s TypeScript resolves the emitted declarations against a different installation than the consumer’s own, so the plugin’s Plugin type never unifies with the consumer’s PluginOption and every consumer needs an as unknown as PluginOption cast. Declaring them as optional peers makes the package resolve the consumer’s copies, so the types unify. Optional because the runtime entries (., /shim, /hydration) need none of them.

  @svebcomponents/build: createTsdownConfig now has an explicit Options return type — the inferred type referenced rollup’s plugin types through non-portable .pnpm paths (TS2742) in the emitted declarations.

• Updated dependencies [c2f1b6c]

• Updated dependencies [c2f1b6c]

• Updated dependencies [8bceff0]

• Updated dependencies [8bceff0]

• Updated dependencies [c2f1b6c]

• Updated dependencies [c2f1b6c]

• Updated dependencies [c2f1b6c]

• Updated dependencies [c2f1b6c]

  • @svebcomponents/ssr@0.1.0
  • @svebcomponents/auto-options@0.1.0

0.0.9

Patch Changes

• 257e5b0: Load package Svelte config during builds and support async SSR when that config enables Svelte’s experimental async compiler mode. Host apps can opt into the async Vite wrapper for Svelte async SSR.

• 257e5b0: Share the Svelte build config helpers (SvelteBuildConfig, mergeCompilerOptions) from a single home in @svebcomponents/ssr via a new @svebcomponents/ssr/svelte-config export, instead of duplicating them in @svebcomponents/build. This removes the risk of the two copies drifting apart.

• fd39f2c: Fix the CLI silently exiting with no output when no component exports could be inferred, and fix the error handler so build failures are reported and exit with a non-zero code.

• 4efae18: Remove a duplicate import type { Options } from "tsdown" in inferComponents.test.ts that broke tsc for the package (introduced by a merge conflict resolution in #79).

• a6370a2: Remove conflicting peerDependency on @svebcomponents/ssr, keeping only the regular workspace dependency since it is imported directly and unconditionally.

• 2c2510b: Generate the SSR renderer entry filename from the declared package export instead of hardcoding ssr.js.

  Previously every SSR build wrote <ssrOutDir>/ssr.js regardless of the declared export. This meant the multi-component setup documented in the build README (e.g. "./button/ssr": "./dist/server/button-ssr.js") produced a dangling export, and two SSR components sharing an output directory overwrote each other’s generated entry.

  inferComponents now derives the entry basename from the declared ssr export path, and a new ssrEntryFileName option on defineConfig (defaulting to "ssr") threads it through svebcomponentsSsr into pluginGenerateSsrEntry. Single-component behavior is unchanged.

• 724f00a: Declare supported Node versions (engines.node: ">=20.19.0") so consumers get a clear error instead of an opaque runtime failure on unsupported Node versions.

• e7e4adf: Fix publint compliance: put the types export condition first so TypeScript resolves declarations as published, add files fields so tarballs only ship dist (and bin.js for the build package), and run publint as part of every publishable package’s build.

• 8913436: Drop test and build tooling from runtime dependencies: vitest, rolldown, typescript, and tslib are no longer installed when consuming @svebcomponents/ssr, and typescript/tslib are no longer installed when consuming @svebcomponents/build. These were only used for tests, type-only imports, or package builds and are now devDependencies (or removed entirely).

• ac6e095: Fix Windows portability issues:

  • @svebcomponents/build now uses path.posix consistently in inferComponents. The values flowing through it come from package.json exports (always posix) and become generated import specifiers, which must stay posix. Previously path.normalize could flip them to backslashes on win32. existsSync filesystem checks remain safe because Node’s fs APIs accept forward slashes on Windows.
  • @svebcomponents/auto-options build script no longer relies on rm -rf, which fails on Windows cmd/PowerShell. It now uses a portable node -e fs.rmSync call to clean stale dist output before tsc.

• Updated dependencies [257e5b0]

• Updated dependencies [257e5b0]

• Updated dependencies [f02d6ee]

• Updated dependencies [cefe6cb]

• Updated dependencies [bea7309]

• Updated dependencies [742c433]

• Updated dependencies [2c2510b]

• Updated dependencies [724f00a]

• Updated dependencies [e7e4adf]

• Updated dependencies [303541d]

• Updated dependencies [0d74921]

• Updated dependencies [94530d0]

• Updated dependencies [4ca91b2]

• Updated dependencies [8913436]

• Updated dependencies [d51f92b]

• Updated dependencies [2f11d81]

• Updated dependencies [f8970a8]

• Updated dependencies [4c038c3]

• Updated dependencies [5c8d636]

• Updated dependencies [ac6e095]

• Updated dependencies [e4fe34f]

• Updated dependencies [1e14cc5]

• Updated dependencies [f75af70]

• Updated dependencies [3a4d68e]

  • @svebcomponents/ssr@0.0.8
  • @svebcomponents/auto-options@0.0.5

0.0.8

Patch Changes

• 1719c09: svebcomponent consumers who use svelte themselves don’t necessarily need the svelte runtime included with their webcomponents as they could share the runtime with the host app. note that this comes with risks, as the svelte runtime is an implementation detail and as such does not guarantee compatibility even between patch & minor versions. if both your web components and your host were built with the same version of svelte you can shave off the cost of including the runtime though

0.0.7

Patch Changes

• 776bbbc: fix: ensure tsdown is a regular dependency

0.0.6

Patch Changes

• b282163: fix: migrate to tsdown to emit types again
• Updated dependencies [b282163]
  • @svebcomponents/ssr@0.0.7

0.0.5

Patch Changes

• 1c5b92f: refactor!: migrate to rolldown

  since the minification logic of rolldown is different than rollup & rolldown is also still in beta, this is a breaking change

• 2d11175: feat: add ‘svebcomponents’ cli tool & ‘svebcomponents.config.ts’ configuration

• Updated dependencies [1c5b92f]

• Updated dependencies [1b1aea0]

  • @svebcomponents/auto-options@0.0.4
  • @svebcomponents/ssr@0.0.6

0.0.4

Patch Changes

• Updated dependencies [a1bc248]
  • @svebcomponents/ssr@0.0.5

0.0.3

Patch Changes

• 6fd10e7: fix: add @rollup/plugin-typescript peer deps
• Updated dependencies [6fd10e7]
  • @svebcomponents/ssr@0.0.4

0.0.2

Patch Changes

• Updated dependencies [8aa8512]
  • @svebcomponents/auto-options@0.0.3
  • @svebcomponents/ssr@0.0.3

0.0.1

Patch Changes

• 5cedd02: fix: set dependencies correctly
• Updated dependencies [5cedd02]
  • @svebcomponents/auto-options@0.0.2
  • @svebcomponents/ssr@0.0.2