Vue

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

.vue

Registry names

vue

Recorded symbols

components · props · events · methods

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 7 types marked as published through delegated analyzers come from the JavaScript, TypeScript analyzers this one hosts for inline blocks; their edges are stored under Vue. The register explains what each label means.

What this analyzer does not resolve

• The template is markup, not symbols. Template elements, attributes and directives are never recorded: a component usage comes from its tag name, a provide/inject key from its argument, and an identifier read in {{ }} or :attr from the expression — so a directive is read, never resolved.
• The seven compiler macros are how a file declares its own surface, so they publish props and events rather than edges. withDefaults(defineProps(xPropsDefaults), …) reads its defaults object within the file: a defaults constant imported from another module yields no defaults, because this lane does not resolve cross-file constants.
• A <style> block is skipped entirely, and it is not the CSS family's either unless a build step writes it out as a real stylesheet file. And a placeholder in a template is read as a name: two corpus files published components literally named COMPONENT_NAME with 64 edges between them, which is what a template awaiting substitution looks like to an identifier reader.

Every line above was written against Vue’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 — .vue. Everything below is about where those files actually sit in a working repository.

• One component per file, and the file's own name is the component's name, so the class symbol, the parent's import and the tag in a template are the same string.
• Options API and <script setup> land in the same component symbol — methods, computed, props, emits, watch, setup and the lifecycle hooks are all members of it — so a codebase mid-migration reads as one graph rather than two.
• A component's real dependencies (a store, a router, an API client) are ordinary imports in its script block, handed to the JavaScript or TypeScript analyzer, so they sit in the same graph as the components it renders. Which of the two runs is decided per script block from the block's declared language rather than from the file extension.

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 and events does this component declare?
3. Which methods does this component define, and what do they call?
4. Which key does this component provide or inject?

What the analyzer sees in code like this

<script setup>
const props = defineProps({ id: String, total: Number })   // bb records: properties id, total
const emit  = defineEmits(['save'])                          // bb records: event save
</script>

<template>
  <!-- bb records: instantiates edge -> InvoiceRow, from the tag name alone -->
  <InvoiceRow :total="props.total" @save="emit('save')" />
</template>

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
• Svelte14 types
• Markdown5 types
• TOML4 types
• XML9 types
• Make8 types
• Protobuf5 types