fix(core): improve bindings detection

[ematipico]

Summary

Closes #8904
Closes #8903

In order to fix the issues, I had to rethink how JS snippets are parsed. Up until now, they were parsed as normal JS files, which turned out be incorrect, because things like {{ duration: 400 }} were incorrectly parserd.

It's safe to assume that JS snippets inside a HTML-ish language should be parsed as an expression, because they must return a value. Hence, I added a new root to the JS language, very much like the root we use for embedded templates. I decided to use a new root to avoid possible conflicts with the semantics and the possible evolution of the feature.

The code has been created via AI, and carefully steerred toward the correct implementation.

Test Plan

Added new tests.

I updated the parsing infra of the JS parser so that we can simulate snippets, using the suffix .inline_expr..

Docs

Not needed

[changeset-bot]

⚠️ No Changeset found

Latest commit: cecce99

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[coderabbitai]

Walkthrough

Adds first‑class support for inline/template expressions by renaming JsExpressionSnipped→JsExpressionSnippet and introducing JsExpressionTemplateRoot; parser now parses Vue/Svelte/Astro template expressions as single-expression roots, with new diagnostics for template-expression errors. Formatter and generated code updated to match the renamed node and to format the new template-root. Linter/semantic updates: JsFileSource now exposes template-expression semantics, no_useless_lone_block_statements now uses file_source, and no_unused_variables consults embedded value references to avoid false positives. Tests for Astro, Svelte and Vue linting were added.

Possibly related PRs

• fix(core): parse astro script as TS #7878 — touches parse_embedded_script/file_handlers/html.rs and how Astro <script> tags map to JS/TS file sources; directly overlaps embedding handling.
• fix(js_parser): allow return statements in Astro frontmatter #8302 — addresses return-statement legality in Astro frontmatter and related parser/embedding behaviour.
• feat(core): improved bindings detection #8642 — integrates embedded-binding/reference checks into noUnusedVariables; closely related to the embedded-reference work here.

Suggested reviewers

• dyc3

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'fix(core): improve bindings detection' is somewhat vague and doesn't clearly convey the main change—reworking JS snippet parsing for HTML-like languages.	Consider a more specific title like 'fix(core): parse template expressions as expressions instead of statements' to better reflect the core change.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description clearly explains the problem, solution, and approach, directly addressing the linked issues and rationale for the architectural changes.
Linked Issues check	✅ Passed	The PR successfully addresses both linked issues: JS snippets are now parsed as expressions (fixing false positives for both noUnusedVariables [#8904] and noUselessLoneBlockStatements [#8903]) via the new JsExpressionTemplateRoot.
Out of Scope Changes check	✅ Passed	All changes are directly related to the stated objective of reworking JS snippet parsing. Typo corrections (JsExpressionSnipped → JsExpressionSnippet) support the core refactoring and are necessary housekeeping.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/false-positives-embeds

---

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

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In
`@crates/biome_js_analyze/src/lint/complexity/no_useless_lone_block_statements.rs`:
- Line 147: Remove the stray dbg!(&statement); call in
no_useless_lone_block_statements.rs (the debug print that spams stderr during
lint runs); simply delete that dbg! invocation (or replace it with a proper
trace/log call if structured logging is needed) so the linter no longer emits
debug output for the `statement` variable.
- Around line 150-153: The JsExpressionStatement match arm is inverted: change
the condition on AnyJsStatement::JsExpressionStatement from
"!file_source.is_embedded_source()" to "file_source.is_embedded_source()" so
embedded sources are suppressed (treated as useful) while regular JS still flags
lone expression statements; update the match arm that currently reads
AnyJsStatement::JsExpressionStatement(_) => !file_source.is_embedded_source()
accordingly.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing fix/false-positives-embeds (cecce99) with next (7e48bd4)}

Summary

✅ 58 untouched benchmarks
⏩ 96 skipped benchmarks¹

Footnotes

1. 96 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[dyc3]

This does not fix the noUselessLoneBlockStatements issue. I think I know what's happening though.

Given this snippet:

<div {...props} transition:slide={{ duration }}>
	{@render children?.()}
</div>

{ duration } gets parsed as if its a full js doc:

JsModule {
  bom_token: missing (optional),
  interpreter_token: missing (optional),
  directives: JsDirectiveList [],
  items: JsModuleItemList [
    JsBlockStatement {
      l_curly_token: L_CURLY@0..2 "{" [] [Whitespace(" ")],
      statements: JsStatementList [
        JsExpressionStatement {
          expression: JsIdentifierExpression {
            name: JsReferenceIdentifier {
              value_token: IDENT@2..11 "duration" [] [Whitespace(" ")],
            },
          },
          semicolon_token: missing (optional),
        },
      ],
      r_curly_token: R_CURLY@11..12 "}" [] [],
    },
  ],
  eof_token: EOF@12..12 "" [] [],
}

If I make it a little different, { duration: 200 }, it thinks duration: is a label, and I get a bunch of false positives for noConfusingLabels.

I think the correct fix for this is to have some other entry point into the js parser to make it so that these get parsed as a JsObjectExpression (which is what it's supposed to be).

[ematipico]

I think the correct fix for this is to have some other entry point into the js parser to make it so that these get parsed as a JsObjectExpression (which is what it's supposed to be).

Yeah, good catch, I believe we so.

[ematipico]

@dyc3 I updated the description of the PR, because I changed completely how the feature should work.

Feedback addressed

[ematipico]

Going to merge this, but let me know if you have some feedback. The PR addresses the concerns