Bug: prefer-const error in try catch

Environment

Node version: 16.13.0 npm version: 8.1.0 Local ESLint version: 8.5.0 Global ESLint version: N/A Operating System: Ubuntu 20

What parser are you using?

@typescript-eslint/parser

What did you do?

Configuration

module.exports = {
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: './tsconfig.json',
    ecmaVersion: 'es2020',
    sourceType: 'module',
  },
  root: true,
  plugins: ['@typescript-eslint'],
  extends: ['plugin:@typescript-eslint/recommended'],
  rules: {
    'prefer-const': 2,
  },
};

function something(): number {
	let x: number;

	function dangerousFunction(): number {
		if (Math.random() > 0.5) throw new Error('Boom')
		return 123
	}

	try {
		x = dangerousFunction() // ESLint: 'x' is never reassigned. Use 'const' instead.(prefer-const)
	} catch (e) {
		return -1
	}

	return x * 20 + 5
}

A set up repo: https://github.com/timvandam/eslint-bug

What did you expect to happen?

It should not error when assigning a variable once in a try catch (as per #15460)

What actually happened?

It does error!

Participation

• I am willing to submit a pull request for this issue.

Additional comments

If I can figure it out I would be willing to submit a pull request. I’m not sure how eslint and the typescript parser interact, but from what I’ve seen while exploring it quickly, the typescript eslint plugin does not change the prefer-const rule whatsoever, it just takes it from eslint

[mdjermanovic]

Your configuration:

ecmaVersion: ‘es2020’,

Per TypeScript ESLint Parser documentation:

When it’s a version or a year, the value must be a number - so do not include the es prefix.

Can you try with ecmaVersion: 2020?

Since 'es2020' isn’t an expected value, I believe it defaults to 5, which affects scoping in a way that prefer-const gets info that the assignment is in the same scope as the declaration, and therefore reports the error.

[timvandam]

Why shouldn’t it error, if you’re not referencing x anywhere else?

I forgot to include that in my code snippet, I added it just now. If x is used below the try catch, the error persists.