fix(vite,devtools-kit): Open in Editor for JSX/TSX components

[NikhilVerma]

Summary

"Open in Editor" never appears for JSX/TSX components. DevTools resolves a
component's source path from instance.type.__file, and nothing sets it for
JSX/TSX — so activeTreeNodeFilePath is empty and the button is never rendered.

@vitejs/plugin-vue attaches __file to every SFC during serve, with the
comment "expose filename during serve for devtools to pickup":

if (devToolsEnabled || (devServer && !isProduction)) {
  attachedProps.push([`__file`, JSON.stringify(isProduction ? path.basename(filename) : filename)])
}

@vitejs/plugin-vue-jsx has no equivalent. It emits only __hmrId, which is a
sha256 hash with no path in it.

Reproduction

https://github.com/NikhilVerma/vue-devtools-tsx-repro

pnpm install && pnpm verify

  module                            plugin                    __file
  ------------------------------------------------------------------------
  /src/components/SfcButton.vue     @vitejs/plugin-vue        yes
  /src/components/TsxButton.tsx     @vitejs/plugin-vue-jsx    NO
  /src/components/PlainTsxButton.tsxplain function            NO

pnpm verify boots the dev server and greps each transformed module — no
browser needed. pnpm dev reproduces it in the UI: select <SfcButton> and the
launch icon is there, select either TSX component and it is gone.

Changes

packages/vite — attach __file to JSX/TSX components in serve mode
(src/jsx-file-injection.ts). Two cases:

1. Components plugin-vue-jsx already tagged with __hmrId (the
   defineComponent pattern) — stamp the same local binding.
2. Plain function/arrow components, which get no __hmrId at all, matched by
   the convention of naming the component after its file. This only fires when
   the module declares that binding itself, so a re-exported import is never
   attributed to the wrong file, and the assignment is narrowed to functions and
   objects so a same-named non-component binding cannot throw under ESM strict
   mode.

packages/devtools-kit — openInEditor now prefers __VUE_INSPECTOR__
whenever vitePluginDetected is true, regardless of host. The
chrome-extension branch was bypassing the already-configured
launch-editor-middleware and falling back to a raw fetch that failed silently.
The fetch fallback is kept for when no Vite plugin is present, with a clearer
error.

packages/devtools-kit — getComponentFileName now handles .jsx/.tsx.
Once __file exists, basename(file, '.vue') still cannot read it:
lastIndexOf('.vue') on Foo.tsx is -1 and substring(0, -1) clamps to '',
so an anonymous defineComponent({}) in a .tsx file falls through to
"Anonymous Component" instead of its filename. Also extends the existing
index.vue suppression to index.jsx / index.tsx.

Relationship to vitejs/vite-plugin-vue#784

I also opened vitejs/vite-plugin-vue#784, which fixes
this in plugin-vue-jsx via the Babel AST. That is the better home for it —
it works for anyone using JSX, including people on the browser extension who
never install this plugin.

These aren't redundant. The upstream fix only reaches components
plugin-vue-jsx tracks for HMR, so plain function components stay uncovered;
and it only helps once released. The change here works today and covers both
shapes. If both land they assign __file to the same value, last write wins,
and the result is identical.

Tests

• packages/vite/__tests__/jsx-file-injection.spec.ts — 10 tests covering both
  injection paths, the imported-binding case, double-stamping, non-JSX files,
  query-suffixed ids, and lowercase filenames
• packages/devtools-kit/__tests__/component/utils.test.ts — 15 tests for
  getComponentName / getInstanceName against .jsx and .tsx files

Verified manually

Against the reproduction, with this branch built and installed:

• Every component carries its path in the component tree
• The launch icon appears for both TSX components
• Clicking it requests /__open-in-editor?file=/…/TsxButton.tsx:0:0 — the same
  shape as the SFC — which returns 200 and opens the file
• With the released plugin restored, all of the above goes back to failing

Supersedes #1102

#1102 was pushed from the wrong branch: it contained a component-highlighter
change rather than any of this, which is why it looked like it was fixing
nothing. Closing it in favour of this. The highlighter change (DOM walking for
content the renderer never created, e.g. v-html / innerHTML) is a separate
issue and I'll raise it on its own if it's wanted.

[netlify]

✅ Deploy Preview for vue-devtools-docs canceled.

Name	Link
🔨 Latest commit	2f0123e
🔍 Latest deploy log	https://app.netlify.com/projects/vue-devtools-docs/deploys/6a79af82ddab0800083e2846