[no-unused-vars] False positive when var is used in @jsxFrag

[dbartholomae]

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

{
  extends: [
    "plugin:@typescript-eslint/recommended",
    "plugin:react/recommended"
  ],
  parser: "@typescript-eslint/parser",
  parserOptions: {
    project: "tsconfig.json",
    sourceType: "module",
    ecmaFeatures: {
      jsx: true,
    }
  },
  rules: {
    "react/prop-types": 0
  }
}

/* @jsx MD */
/* @jsxFrag Fragment */
import MD from "..";
import { Fragment } from ".";
<>Test</>;

Expected Result

This should lint just fine.

Actual Result

warning  'Fragment' is defined but never used  @typescript-eslint/no-unused-vars

Versions

package	version
@typescript-eslint/eslint-plugin	4.1.1-alpha.5
@typescript-eslint/parser	4.1.1-alpha.5
TypeScript	4.0.2
ESLint	7.8.1
node	12.18.3

[dbartholomae]

Not sure if this will be solved by #1856 but linking the issue as it might be related

[bradzacher]

We have parserOptions for both the pragma and the fragment name, both of which we are able to infer from the tsconfig if you're using type-aware parsing.

However this style of config will need to be built specifically - which is why support for inline config comments has not implemented.

Happy to accept a PR.

[dbartholomae]

Thanks! I'll first need to finish the project where I'm using this, but happy to work on a PR for this next. I haven't yet contributed to typescript-eslint, so a small hint where to start would be greatly appreciated (only if it doesn't take you much time). It seems like the jsx pragma is already implemented? If you think, adding the jsxFrag pragma is a good first issue, I'm happy to take it, though a hint where to start would be greatly appreciated (I would assume somewhere in scope-manager?).
This might not be the most important ticket for this library at the moment, though, so if there is another issue where it would make more sense for me to help, I would be happy to do so :)

[bradzacher]

The way it is set up is such that concerns are separated.

• typescript-estree is solely concerned with coordinating with TS to produce an ESTree AST.
• scope-manager is solely concerned with doing scope analysis using the provided options.
• parser is concerned with coordinating the above packages in the context of an ESLint run.

So the feature would live in parser.
This is where we currently prepare the scope analysis options before calling the analyser. Right now this code just fills in the blanks if you're using type-aware parsing.

typescript-eslint/packages/parser/src/parser.ts

Lines 137 to 171 in ec7449d

	if (services.hasFullTypeInformation) {
	// automatically apply the options configured for the program
	const compilerOptions = services.program.getCompilerOptions();
	if (analyzeOptions.lib == null) {
	analyzeOptions.lib = getLib(compilerOptions);
	log('Resolved libs from program: %o', analyzeOptions.lib);
	}
	if (parserOptions.jsx === true) {
	if (
	analyzeOptions.jsxPragma === undefined &&
	compilerOptions.jsxFactory != null
	) {
	// in case the user has specified something like "preact.h"
	const factory = compilerOptions.jsxFactory.split('.')[0].trim();
	analyzeOptions.jsxPragma = factory;
	log('Resolved jsxPragma from program: %s', analyzeOptions.jsxPragma);
	}
	if (
	analyzeOptions.jsxFragmentName === undefined &&
	compilerOptions.jsxFragmentFactory != null
	) {
	// in case the user has specified something like "preact.Fragment"
	const fragFactory = compilerOptions.jsxFragmentFactory
	.split('.')[0]
	.trim();
	analyzeOptions.jsxFragmentName = fragFactory;
	log(
	'Resolved jsxFragmentName from program: %s',
	analyzeOptions.jsxFragmentName,
	);
	}
	}
	}
	const scopeManager = analyze(ast, analyzeOptions);

The feature could be to iterate the comments in the AST, and then overwrite the the option that we find config comments for. This would match TS's behaviour, as you can configure jsxFactory in your tsconfig and overwrite it per-file with a config comment.

[dbartholomae]

Thanks! Unfortunately I did not get to this issue over the last weeks and due to changes in priorities won't be able to take it in the near future :(
Feel free to either close or leave open, depending on your policy for this repo :)

[daryazata]

@dbartholomae
I'm facing the same issue still, used vars are claimed as unused quite randomly, see an example below:

[bradzacher]

@daryazata please file a separate issue. That is entirely unrelated to this issue.