Right now for a developer to define their custom elements, they must explicitly call svelteRetag(...) with their custom element configuration.
Relates to #13.
Describe the proposed solution
If the user is using Vite, we could define a custom plugin which will automatically parse and transform instances of <svelte:options customElement=... />, normalizing it down to remove the customElement definition (performed in pre processing) but retaining that information in scope for later processing. Then a second transformer running in post processing can inject the necessary JS to perform the initialization automatically in the emitted JS.
Describe the problem
Right now for a developer to define their custom elements, they must explicitly call
svelteRetag(...)
with their custom element configuration.Relates to #13.
Describe the proposed solution
If the user is using Vite, we could define a custom plugin which will automatically parse and transform instances of
<svelte:options customElement=... />
, normalizing it down to remove thecustomElement
definition (performed inpre
processing) but retaining that information in scope for later processing. Then a second transformer running inpost
processing can inject the necessary JS to perform the initialization automatically in the emitted JS.This could require AST (abstract syntax tree) processing. If so, consider using
zimmerframe
, since that will be what is used in Svelte 5, per https://github.com/micantoine/svelte-preprocess-cssmodules/pull/100#issue-1978258445.Alternatives considered
None.
Importance
would make my life easier