Import autocomplete in VS Code ends in undefined for .vue files distributed as source code in npm package

[kleinfreund]

At my job, we have an npm package that contains Vue components in the form of .vue SFC files that are distributed as source code (no bundling, no compiling, just the .vue files as-is). In a consuming project, the auto completion suggestion for adding the appropriate imports while typing in a component's template section behaves strangely for this package:

Consider the following file in the consuming project and that node_modules/my-component-library contains the file PackageIcon.vue:

Test.vue:

<template>
  <PackageIco
  <!--       ^ trigger completion suggestions here (usually Ctrl+Space) -->
</template>

<script setup lang="js">
</script>

This will show one completion suggestion: PackageIconVue. Accepting it leads to the following change:

Test.vue:

<template>
  <PackageIconVue
</template>

<script setup lang="js">
import PackageIconVue from "my-component-library/src/PackageIcon/PackageIcon.vueundefined";

</script>

Now, I've found issues and discussions here talking about the additional Vue string in the imported symbol and while I'd prefer PackageIcon, it doesn't cause any real issues.

However, how come the import path contains undefined at the end?

This only seems to happen for Vue components that are discovered in node_modules/via package module specifiers. Imports local to the project work fine and also don't append the Vue string.

Also, when I use TypeScript (i.e. lang="ts"), the import is further broken by the addition of the type keyword:

Test.vue:

<template>
  <PackageIconVue
</template>

<script setup lang="js">
import type PackageIconVue from "my-component-library/src/PackageIcon/PackageIcon.vueundefined";

</script>

Though strangely, this doesn't always reproduce.

I wanted to raise this as a discussion first because I'm not sure if this is an environment problem and not a bug. Also, I can't really offer a reproduction as the library is private.

[kaminagakur4]

I asked Claude to lay out my solution in a straightforward, step-by-step manner, so this should be pretty easy to follow. Let me know if you need any extra help.
Two of your three symptoms are the same bug wearing different clothes, and it's one guard. Worth separating them before anyone hunts the third.

1. The guard. In packages/typescript-plugin/lib/common.ts, resolveCompletionResult() only rewrites a component entry when the entry's source is a .vue path:

for (const vueExt of vueOptions.extensions) {
  const suffix = capitalize(vueExt.slice(1)); // .vue -> Vue
  if (item.source.endsWith(vueExt) && item.name.endsWith(suffix)) {
    item.name = capitalize(item.name.slice(0, -suffix.length));
    …
    data.__vue__componentAutoImport = { oldName, newName };
    break;
  }
}

When that if doesn't fire, __vue__componentAutoImport is never set — and every later fixup is gated on it.

2. That's why you keep PackageIconVue. The name strip lives inside the same if.

3. And that's why lang="ts" gives you import type. resolveCompletionEntryDetails(), in the same file, rewrites 'import type ' + oldName + ' from ' into 'import ' + newName + ' from ' — but that block sits inside if (data.__vue__componentAutoImport). No flag, no rewrite, so TypeScript's type-only import survives verbatim. Your third symptom isn't separate; it's the second one's shadow. Fix the guard and both go away together.

4. Where the .vue in the path comes from, since it looks wrong but isn't: packages/typescript-plugin/lib/requests/resolveModuleName.ts resolves with allowArbitraryExtensions: true, so PackageIcon.vue goes through a PackageIcon.d.vue.ts declaration, and TypeScript's own processEnding() routes *.d.*.ts to tryGetRealFileNameForNonJsDeclarationFileName(), which maps it back to …/PackageIcon.vue. That part is TS behaving as designed. It also means TS isn't the one appending anything: removeFileExtension doesn't know .vue, so processEnding returns such a name unchanged rather than concatenating an extension onto it.

5. What would pin the trailing undefined for a maintainer. The _vue:resolveAutoImportCompletionEntry handler in packages/typescript-plugin/index.ts re-asks TypeScript for details, passing source and a mutated data object — the entry's own ts.CompletionEntryData with __vue__* fields added to it. Logging textChanges[].newText as returned there, before resolveCompletionEntryDetails() runs, says whether the undefined arrives from TS or is produced on the Vue side. I read the source rather than ran it, so I'd rather hand you that one measurement than guess a line.

6. Something you can do today, on the library side. Give the package a real exports map (with types pointing at the generated .d.vue.ts). With exports, TypeScript builds the specifier from your declared subpaths instead of walking the node_modules file path, so you get my-component-library/PackageIcon rather than a raw src/…/PackageIcon.vue — which sidesteps all three symptoms instead of working around them, and gives consumers a stable public surface either way.