fix: custom extensions work with the native compiler

[brenelz]

Fixes #297.

Problem

solidPlugin({ compiler: 'native', extensions: ['.mdx'] }) fails on every custom-extension file with:

[solid] Unknown file extension: Please provide a valid file extension: .js, .mjs, .jsx or .cjs for JavaScript, or .ts, .d.ts, .mts, .cts or .tsx for TypeScript

The native compiler picks its parser dialect from the file extension, which is why the transform already builds a borrowed-extension filename for ids it doesn't recognize (foo.mdx → foo.mdx.jsx, or .tsx when the extension is registered with typescript: true). The lazy and refresh passes use it — but the native JSX transform itself still passed the raw id, so @dom-expressions/compiler rejected the file. compiler: 'babel' was unaffected because that path names its parser plugins explicitly, so the filename never matters.

Fix

Pass the same borrowed nativeFilename to the JSX transform that the lazy and refresh passes already receive. For standard extensions nativeFilename === id, so nothing changes there (sourcemap sources included).

Verification

Reproduced with a minimal Vite build of an .mdx entry containing JSX under compiler: 'native', extensions: ['.mdx']:

• before: build fails with the "Unknown file extension" error above
• after: build succeeds and the output contains the compiled Solid template for the file

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: df05dcf

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
vite-plugin-solid	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vite-plugin-solid@301

commit: df05dcf

[ryansolid]

Verified against #297: reproduced the "Unknown file extension" failure on next.24 with a .mdx build under compiler: 'native', and confirmed this branch fixes it (compiled template present in the output). The analysis is right — nativeFilename was built for exactly this case and the lazy/refresh passes already consumed it; the JSX transform was the one holdout. For standard extensions nativeFilename === id, and the ssr example suite passes 12/12, so no behavior change there. Approving. Non-blocking: none of our suites exercise options.extensions, so this has no regression coverage — I'll take that as a follow-up on our side (it needs a new fixture, which is beyond the scope of this fix). Thanks!