Svelte

The registry row this page is generated from

Read at render time from the same family row the register reads, so nothing in this block can disagree with it.

Extensions

.svelte

Registry names

svelte

Recorded symbols

components · methods · state

Relationship types this analyzer constructs

14 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.

14 constructed, 0 not constructed. The 10 types marked as published through delegated analyzers come from the JavaScript, TypeScript analyzers this one hosts for inline blocks; their edges are stored under Svelte. The register explains what each label means.

What this analyzer does not resolve

• Runes are compiler macros: the variables they initialise are the symbols, and the rune calls themselves are not call targets. The sharp edge is the invoking/value-taking split — $effect(…), $effect.pre, $effect.root, $effect.untracked, $derived.by and $host invoke what they are given, so a named function handed to one does produce a call edge, while $derived(expr), $state(0) and $bindable(v) hand over a value and produce none.
• The rune test is on the full dotted name plus its leaf, and a bare $ prefix is never enough. The same $name.member shape is how ordinary user data is written — $order.scoops, $value.foo, $formData.dob — alongside SvelteKit's $lib import alias, which appears 3,549 times in the corpus — so two runes are recognised as exact names only, and a user's own $-prefixed function stays a call.
• Template elements, attributes and directives are never symbols. A component usage comes from its tag and an on: handler from the identifier in its expression, so on:click={() => doThing()} resolves through the call it makes rather than through the directive, and a v-for-style loop variable or a slot prop declared in the markup shadows the script binding of the same name rather than publishing a duplicate.

Every line above was written against Svelte’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.

Where you meet it in a repository

Recognised by extension — .svelte. Everything below is about where those files actually sit in a working repository.

• export let is how a Svelte 4 component declares a prop and $props() how a Svelte 5 one does; both land as properties on the component symbol, so a codebase spanning both styles reads the same way.
• context="module" gives a file a second, instance-free script. Its exports are file-scope bindings rather than members of a component, so a store declared there belongs to the file.
• SvelteKit adds +page.svelte and +layout.svelte route files plus server/ code; those are still .svelte and index as components, and the framework's own routing table is not part of the graph.

Questions this index answers

Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.

1. Which components does this template render?
2. Which props does this component export?
3. Which reactive values does this component declare?
4. Which function does this $effect hand to the compiler?

What the analyzer sees in code like this

<script>
  export let total = 0                   // bb records: property total on the component
  $: doubled = total * 2                 // bb records: variable doubled (a reactive declaration)
  $effect(() => track(total))            // bb records: calls -> track, an invoking rune
</script>

<!-- bb records: instantiates -> InvoiceRow, and the on: handler's call edge -->
<InvoiceRow {total} on:save={save} />

Symbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.

Languages that turn up in the same repository

Web, data & config — the count beside each name is how many relationship types that family’s analyzer constructs.

• SQL10 types
• HTML14 types
• CSS8 types
• SCSS / Sass10 types
• JSON9 types
• YAML8 types
• GraphQL8 types
• HCL / Terraform10 types
• Vue14 types
• Markdown5 types
• TOML4 types
• XML9 types
• Make8 types
• Protobuf5 types