fix(vue): an import through @/ or ~/ in a Vue project links the module's file

[colbymchenry]

Problem

In any project the Vue resolver detects (a vue / nuxt dependency, or any .vue file), every imports reference named by a module path went through vueResolver.resolve before the import resolver did. For @/… and ~/…, its Patterns 4 and 5 mapped the path to src/… by hand and returned getNodesInFile(path)[0] at 0.9 confidence. That is whichever node of the file came first, which is often not the file node.

Fresh index of a fixture, vue in package.json:

import	with Vue (main)	without Vue
@/flags/registry (from a .ts)	constant REGISTERED_FLAGS	file registry.ts
@/table (from an SFC's <script setup>)	constant COLUMNS	file table.ts
~/utils/helper	constant flagged	file helper.ts
@/components/Foo.vue, @/layout	the component	file
#app/where (tsconfig #app/* → client/*)	the importing file itself (the Nuxt virtual-module rule)	file client/where.ts

Consequences:

• Sync walks from a module or barrel that is added or deleted to the files importing it: fix(sync): imports through a re-exporting module follow it when it is deleted or added #2512's reopenReferencesThroughAddedFiles/…RemovedFiles and fix(sync): a lazy route relinks a page that appears below its barrel #2560's reopenReferencesThroughBarrels. They follow imports edges into the file node (getImportsInto('file:…')), so in Vue projects they never found these importers. Found while validating fix(sync): a member reference through an import binding links its module when the module changes #2630, which had to work around it for member calls.
• Which node [0] is depends on the order a file's nodes were stored, so a sync and a fresh index of the same tree could disagree: vue-realworld below.
• The #app/… alias edge pointed at the importing file, so the module's dependents missed its importers.

Fix

src/resolution/frameworks/vue.ts. For a module-path import (isJsPathImportRef):

1. When the import resolver finds the module's file, return null and let it link that file. It follows tsconfig paths, workspace packages and the same @/ / ~/ → src/ fallbacks Patterns 4/5 hard-coded, with each language's extensions. A path that resolves only to a folder doesn't count (the context's fileExists is true for directories).
2. Otherwise, for @/ and ~/ from a plain script, resolve the path the way an SFC's import would: the vue extension list, which adds .vue and /index.vue. Link that file node (import Layout from '@/layout' → src/layout/index.vue). This is the one thing Patterns 4/5 found that the import resolver doesn't from a .ts/.js file: what Vue CLI's bundler resolves.
3. Only then the Nuxt virtual-module sink (#imports, #components, …), unchanged, for modules no project file is.

Patterns 4 and 5 (from the original Vue support, #66) are removed. No other resolver, no extraction and no schema change.

Validation

Tests. __tests__/vue-module-imports.test.ts has 4 tests; all 4 fail on main (run in a detached worktree at baf1906):

• every module-path shape above links its file;
• resolvedBy is import wherever the import resolver finds the file, and framework only for @/layout's index.vue;
• a sync after a barrel (src/components/index.ts: export const VERSION = 1; export * from './Button') is added equals a fresh index of the final tree;
• the same when that barrel is deleted. On main both leave Button's edges exact-match / import the other way round from a fresh index.

Mutations: dropping step 2 loses @/layout's edge, and testing step 1 by a non-null path instead of a file node loses it too. Each fails the first two tests.

Related suites (every vue*, sync*, framework, import, alias, route and SFC test file): 72 files, 914 tests passed. Full suite: 7,251 passed, 0 failed, 82 skipped (Windows).

Fresh-index A/B, main baf1906 against this PR, with the same kernel: Vue repos from the earlier kits, non-Vue controls. Edges that differ are paired by site (source, kind, line, col, refName):

repo	.vue files	changed edges	what changed
vue-realworld	20	51	31 same target, framework → import; 12 component → file; 8 constant → file
vue-element-admin	131	115	67 same target, framework → import; 48 component → file (index.vue folders)
vue3-element-admin	143	453	439 same target, framework → import; 14 component → file
vben	695	0	(its apps import through #/, not @/)
nuxt-movies, laravel-realworld	42, 1	0
ts-express, proshop (React), gin (Go)	0	0

Every changed edge is a module-path imports edge re-pointed at the module's file node at the same site. Nodes and files are byte-identical on all 9 repos, and no edge was removed or added.

Sync A/B: every 7th file held out, emptied, or deleted, then synced; each arm compared with its own fresh index.

scenario	vue-realworld	vue-element-admin	vue3-element-admin	nuxt-movies, laravel-realworld, ts-express
held out	0 → 0	8 → 8	0 → 0	0 → 0
emptied	4 → 0	18 → 18	182 → 182	0 → 0
deleted	0 → 0	12 → 12	8 → 8	0 → 0

vue-realworld's 4: on main, @/common/jwt.service linked a constant in the fresh index but the file node after the sync, because the first node changed with the storage order. The other residues are line-for-line identical on both arms. vben is left out of the sync runs: its syncs fail with FOREIGN KEY constraint failed on main too (#2565, fix in #2574), and its fresh graph is unchanged.

🤖 Generated with Claude Code