bas950 / eslint-plugin-no-one-time-vars

Disallows one-time variables

What I use

eslint-plugin-no-one-time-vars's Issues

Issue with functions with the same name as variables in other scopes.

In specific conditions, no-one-time-vars does not detect some single-use variables. This affects 2.2.0 and 2.2.1.

There is some interesting behavior when you have a function with the same name:

{
  const test = 1;
  console.log(test);
}
{
  const test = 2;
  console.log(test);
}
function test() {}
test();

In this case, the second block with the single-use variable is detected, but the first block is not. Adding more blocks results in all of them being detected, except for the first one. With only 1 block, no errors are found.

Sometimes modifies logic when one-time-var is outside of a scope

Issue
When a one-time-var is set to the result of a method with a side-effect which is accessed in a different function/scope, behavior could be incorrectly modified.

It could potentially affect code with intervals, callbacks, or global variable modification. This may be difficult to detect.

Examples

function example() {
	clearInterval(interval);
}
const interval = setInterval(example, 3000);

// interval is no longer created
function example() {
	clearInterval(setInterval(example, 3000));
}

Complex code with destructuring breaks with --fix

Issue:
When using this plugin on code such as:

const [, foo] = "foobar".match(/regex/) || [];
console.log(foo);

and running it using the --fix option, the code is incorrectly changed.

Expected:

console.log(("foobar".match(/regex/) || [])[1]);

Actual:

console.log("foobar".match(/regex/) || [][1]);

Rule should not trigger on export variables

For files that export variables, but only use it once, this rule may remove them, which can break imports in other files.

Example:

// file1.ts
export const test = doSomething(),
  test2 = test.doSomething();

// file1.ts
export const test = doSomething();
export const test2 = test.doSomething();

In these cases, the test variable may be removed, which could break code in another file:

// file2
import { test, test2 } from "./file1"; // Module 'file1' has no exported member 'test'.