Fix main build: restore PartTag::JsxImport

[robobun]

What does this PR do?

Main at 6089d0e does not compile:

error[E0599]: no variant, associated function, or constant named `JsxImport` found for enum `PartTag`
    --> src/js_parser/p.rs:1917:45

(also at src/js_parser/parse/parse_entry.rs:1966 and :1981)

This is a semantic conflict between two PRs that each passed CI on their own merge base:

• Remove dead code from platform/darwin, webcrypto, sqlite, NodeVM, ast #36833 removed the then-unused JsxImport, CjsImports, and ReactFastRefresh variants from PartTag in src/ast/nodes.rs as dead code.
• bundler: tree-shake the automatic JSX runtime import when all JSX is dead #35472, written before that removal, started tagging synthesized JSX runtime imports with PartTag::JsxImport in the parser and matching on it in LinkerContext.rs.

The fix re-adds the JsxImport variant in its old position. The other two removed variants are still unused and stay gone. PartTag has no explicit repr and is never serialized, so the variant's position carries no meaning; matching the old order keeps the diff minimal against history.

Why a test change?

The build failure itself is the regression, so any test proves fail-before. The added test pins the one path of #35472's feature the suite did not cover: transpile-only output (--no-bundle, the same single-file path the runtime transpiler uses) never tree-shakes parts, so the synthesized JSX runtime import must survive even when every JSX expression is dead. Verified the other direction (bundler drops the import for dead JSX) is already covered by the autoImportTreeShaking tests from #35472, which now compile and pass again.

Verification

• cargo check -p bun_js_parser fails with 3x E0599 before, clean after
• bun bd builds
• bun bd test test/bundler/bundler_jsx.test.ts: 48 pass, 4 todo (pre-existing), 0 fail

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 9 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d83aabd3-ca8e-4036-9b2d-29f181d689c3

📥 Commits

Reviewing files that changed from the base of the PR and between 6089d0e and 6c88dc3.

📒 Files selected for processing (2)

• src/ast/nodes.rs
• test/bundler/bundler_jsx.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 6:56 PM PT - Aug 7th, 2026}

@robobun, your commit 6c88dc3 is building: #90435

[claude]

LGTM — one-line build fix restoring an enum variant that live code references.

What was reviewed:

• Confirmed PartTag::JsxImport is referenced at 4 sites (p.rs:1917, parse_entry.rs:1966/1981, LinkerContext.rs:2763) and CjsImports/ReactFastRefresh remain unused.
• No exhaustive match on PartTag anywhere — all uses are == or struct-init, so inserting a variant is inert elsewhere; enum has no repr and is never serialized.
• New AutoImportKeptWhenNotBundling test mirrors the sibling AutoImportKept* regex assertions with (_\w+)? for the transpile-only hashed alias.

Extended reasoning...

Overview

The PR restores the JsxImport variant to the PartTag enum in src/ast/nodes.rs (single line) and adds one itBundled test case to test/bundler/bundler_jsx.test.ts. This resolves a semantic merge conflict: #36833 deleted the variant as dead code while #35472 (merged after, written before) started using it, leaving main uncompilable with three E0599 errors.

Security risks

None. This is a pure enum-variant addition to an internal AST tag type with no I/O, no user-facing surface, and no serialization.

Level of scrutiny

Low. Main does not build without this line; the fix is mechanically forced by the compiler errors. I grepped the tree to confirm the four live use sites (src/js_parser/p.rs:1917, src/js_parser/parse/parse_entry.rs:1966 and :1981, src/bundler/LinkerContext.rs:2763) and that the two other variants #36833 removed (CjsImports, ReactFastRefresh) remain unreferenced and correctly stay deleted. No code exhaustively matches on PartTag (all consumers use == comparison or field init), so inserting a variant cannot silently change behavior at any other site. The enum has no #[repr] and is never serialized, so discriminant position is irrelevant — the PR description's rationale checks out.

Other factors

The added test follows the exact itBundled conventions of the surrounding autoImportTreeShaking describe block (same regex shape as AutoImportKeptWhenJsxSideEffectsTrue, with (_\w+)? added to match the hashed alias that transpile-only mode emits). It pins the bundling: false path, which the existing suite from #35472 did not cover, so it is additive and non-redundant. PR description reports bun bd test bundler_jsx.test.ts at 48 pass / 4 todo / 0 fail. No prior reviewer comments to address.