feat(js_semantic): support jsxFactory and jsxFragmentFactory

[h-a-n-a]

Summary

closes #3682

Supported option javascript.jsxFactory and javascript.jsxFragmentFactory.

For javascript.jsxFactory, it controls the JSX factory name and for javascript.jsxFragmentFactory, it controls the JSX fragment factory name. Both of them work as long as javascript.jsxRuntime is set to ReactClassic.

JSX usages are now scope-aware. It can track in-scope usages.

// With `jsxFactory` set to `"h"`
function App() {
  const h = () => {};
  return <div></div> // ✅
}
<div></div> // ❌ Cannot find variable `h`

Changes to rule noUnusedImport

For input,

import { h, Fragment } from "preact";
<div />;
<div></div>;
<></>

with option:

{
  "linter": {
    "rules": {
      "correctness": {
        "noUnusedImports": "error"
      }
    }
  },
  "javascript": {
    "jsxRuntime": "reactClassic",
    "jsxFactory": "h",
    "jsxFragmentFactory": "Fragment"
  }
}

Previously:

Both h and Fragment are marked as unused.

Currently:

Both h and Fragment are marked as used.

Changes to rule noUndeclaredVariables

For input,

function App({ children }) {
	return <div>{children}</div>;
}

<></>

with option:

{
  "javascript": {
    "jsxRuntime": "reactClassic",
    "jsxFactory": "h",
    "jsxFragmentFactory": "Fragment"
  }
}

Previously:

Linter will not complain. As, by default, for "reactClassic", we want to make it compatible with both modern and legacy compilers.

Currently:

Linter reads jsxFactory and jsxFragmentFactory. It will complain both h and Fragment are not imported. If jsxFactory and jsxFragmentFactory are resolved to namespace React, linter will not complain for compatibility.

Checklist

• Add jsx_factory and jsx_fragment_factory support for SemanticEventExtractor (scope-aware)
• Support parsing qualified syntax of jsx_factory and jsx_fragment_factory
• Add an ad-hoc validation that emits an error/warning in case of incorrect configuration

BREAKING CHANGES

• UnresolvedReference::tree is removed as the binding does not guarantee it to be a JsIdentifier anymore. It could be a JSX element or a JSX fragment.
• SemanticEventExtractor::enter added a context for passing down jsxFactory and jsxFragmentFactory. It's a little bit weird to add. I would be grateful if you could help me find a better solution.

Test Plan

Tests are added.

[codspeed-hq]

CodSpeed Performance Report

Merging #3761 will not alter performance

_{Comparing h-a-n-a:issue-3682 (f5f7ab0) with main (bcad101)}

Summary

✅ 107 untouched benchmarks

[h-a-n-a]

JsxFactory only stores its namespace. We eagerly parse the expression to support configuration validation.
Using React instead of React.createElement or React.Fragment to make it more performant.

[h-a-n-a]

I don't know if this is the right place to put, thinking of this is a quite general utility.

[h-a-n-a]

This will be considered as a breaking change as the binding does not guarantee it to be a JsIdentifier anymore. It could be a JSX element or a JSX fragment. Also biome_js_semantic releases the crate.

[h-a-n-a]

I'm also thinking of adding a test case for configuration. It will be great if someone can tell me the best place to put it.

[h-a-n-a]

@ematipico Hi! This PR is ready for review. But it contains some breaking changes which seems hard to avoid. Would you please help me see if there's a better choice to do that? ❤️

[Conaclos]

Hi @h-a-n-a,

If I understand correctly, you create a binding between the imported jsxFactory and jsxFragmentFactory and all visited jsxEleemnt and jsxFragment respectively.

I understand what you are trying to achieve here, but I have mixed feelings because it is not really a binding: usually a binding binds a declaration to its usages. Here the usage will be generated by a compiler ; it is not present yet.

We could perhaps create a dedicated event for this use case. Let me think about it and come back later this week when I have a clearer view.

[h-a-n-a]

Hi @h-a-n-a,

If I understand correctly, you create a binding between the imported jsxFactory and jsxFragmentFactory and all visited jsxEleemnt and jsxFragment respectively.

I understand what you are trying to achieve here, but I have mixed feelings because it is not really a binding: usually a binding binds a declaration to its usages. Here the usage will be generated by a compiler ; it is not present yet.

We could perhaps create a dedicated event for this use case. Let me think about it and come back later this week when I have a clearer view.

I had the same feeling too when I was implementing this feature. I had to do all kinds of breaking changes to make this work even like casting the UnresolvedReference to a non-js binding syntax.

Thank you for your reply and I'd be happy to fix this in the future.