Package
@flue/vite@2.0.3 with Vite 8.x.
Reproduction
-
Create a .tsx module containing a type-only import and JSX, and a static
.md import:
import type { Props } from './props';
import instructions from './instructions.md';
export const view = <div>{instructions}</div>;
-
Build with the Flue Vite plugin.
The markdown transform calls parserLangForFile('view.tsx'), but the current
implementation returns js. The parser then rejects valid TSX syntax.
A second independent reproduction occurs when another Vite plugin owns a
virtual skill registry. Given an importer ID such as
\\0agents:skills:/workspace/src/skills that reaches a resolved
/workspace/src/skills/example/SKILL.md, Flue's markdown resolver throws
Skill import ... reached resolution untransformed instead of delegating the
edge to the plugin that owns the virtual namespace.
Expected behavior
.tsx and .jsx files are parsed with the corresponding JSX-aware parser.
- A
SKILL.md import from an explicitly external virtual registry is left for
that registry's resolver; Flue should keep rejecting genuinely untransformed
Flue imports from ordinary JS/TS importers.
Proposed fix
The smallest fix is to map .tsx → tsx and .jsx → jsx in
parserLangForFile, and return null from the markdown resolver only when the
importer starts with \\0agents:skills:. A focused test can cover both cases
without depending on a particular application.
The current main branch (832ad2ee, published as 2.0.3) still reproduces both
failures.
Package
@flue/vite@2.0.3with Vite 8.x.Reproduction
Create a
.tsxmodule containing a type-only import and JSX, and a static.mdimport:Build with the Flue Vite plugin.
The markdown transform calls
parserLangForFile('view.tsx'), but the currentimplementation returns
js. The parser then rejects valid TSX syntax.A second independent reproduction occurs when another Vite plugin owns a
virtual skill registry. Given an importer ID such as
\\0agents:skills:/workspace/src/skillsthat reaches a resolved/workspace/src/skills/example/SKILL.md, Flue's markdown resolver throwsSkill import ... reached resolution untransformedinstead of delegating theedge to the plugin that owns the virtual namespace.
Expected behavior
.tsxand.jsxfiles are parsed with the corresponding JSX-aware parser.SKILL.mdimport from an explicitly external virtual registry is left forthat registry's resolver; Flue should keep rejecting genuinely untransformed
Flue imports from ordinary JS/TS importers.
Proposed fix
The smallest fix is to map
.tsx→tsxand.jsx→jsxinparserLangForFile, and returnnullfrom the markdown resolver only when theimporter starts with
\\0agents:skills:. A focused test can cover both caseswithout depending on a particular application.
The current main branch (
832ad2ee, published as 2.0.3) still reproduces bothfailures.