Deprecate no-use-before-declare rule for typescript 2.9+

[waseemahmad31]

PR checklist

• Addresses an existing issue: fixes Task: document the deprecation of no-use-before-declare #4666
• New feature, bugfix, or enhancement
  • Includes tests
• Documentation update

Overview of change:

deprecate no-use-before-declare for TS 2.9+

[palantirtech]

Thanks for your interest in palantir/tslint, @waseemahmad31! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

[JoshuaKGoldberg]

Super, thanks!

[karol-majewski]

It seems like discouraging TSLint users from using no-use-before-declare might have been premature. There is a class of errors this rule helps catch and these errors are not detected by TypeScript itself.

Consider this example:

const consumer = () => {
  console.log(variable); // no-use-before-declare: "variable 'variable' used before declaration"
};

consumer();

const variable = 'foo';

This snippet represents perfectly valid TypeScript — no compile-time error will be issued. Yet, an attempt to run it will cause a runtime exception.

See TypeScript playground.

Thanks to @OliverJAsh for providing an example.

[JoshuaKGoldberg]

@karol-majewski one difficulty of rules like no-use-before-declare is figuring out which nodes are truly used before declaration vs. ones that just seem to be used before declaration.

const consumer = () => {
    setTimeout(() => {
        console.log(variable);
    }, 1);
};
  
consumer();
  
const variable = 'foo';

The rule has been somewhat marked as deprecation for a while (#4666); if you'd like to see it un-deprecated or generally re-implemented please file a new issue.

[OliverJAsh]

The docs seem to suggest this rule was deprecated because it no longer has any use (since var is no longer used). Is that correct?

In addition to @karol-majewski's point about catching runtime errors: I would still like this rule for a code style preference of mine: enforcing single direction of code definitions—details at top, composition/usages below. E.g.

Without

const y = 1;

const foo = () => {
    x;
    y;
}

const x = 1;

With

const x = 1;
const y = 1;

const foo = () => {
    x;
    y;
}

Of course this is subjective—just pointing out that the rule was useful for enforcing this preference, for people/teams who like it.

[Burgestrand]

I'm a new user of typescript, and received this warning. However, I believe it's unclear:

Please use the built-in compiler checks instead.

Does this mean I need to enable a compiler option in order to have the same guarantees as I would have had before this rule was deprecated?

I propose changing the message to either "This rule is no longer necessary and can be safely removed" or pointing the user (in this case me) to documentation for which compiler options are relevant.

However, to be fair, it seems to me the discussion here isn't quite over yet.

[bolatovumar]

@Burgestrand I can't find an equivalent compiler option for this rule but it looks like you don't really need this rule if you don't use the "var" keyword. So, if you have the "no-var-keyword" rule enabled then this rule is not needed at all.

[Burgestrand]

@bolatovumar Great, thank you!

[karol-majewski]

@bolatovumar None of the examples in this thread is using the var keyword. 🤔 Yet using no-use-before-declare would have helped catch errors for them.

[bolatovumar]

@karol-majewski you get compiler warnings if you use a const or let variable before it's declared so you don't need this rule in that case.

[karol-majewski]

@bolatovumar TypeScript doesn't issue any warnings for this piece of code and yet it breaks in runtime:

const consumer = () => {
  console.log(variable);
};

consumer();

const variable = 'foo';

See for yourself in TypeScript playground.

[bolatovumar]

@karol-majewski right, I see. You might wanna file a separate issue as @JoshuaKGoldberg suggested above . I'm not actually sure why this rule is deprecated specifically for TS 2.9+ so I can't really add much more here.

[JoshuaKGoldberg]

Posting again here: the rule seems to have some buggy behavior, such as the false positive mentioned in #2551. If you'd like the rule to be un-deprecated despite that (maybe the bug doesn't exist? maybe it's worth it to keep the rule?) please file a new issue so we can discuss there. PR responses aren't very search-discoverable.

Also, keep #4534 in mind: TSLint is in the process being deprecated.

Same goes for suggestions to improve the rule's docs or error messaging. I'm all for improving docs, but we should discuss them in a dedicated thread. It's hard to keep track of this one... 😞

[ikokostya]

please file a new issue so we can discuss there

Come on. I created new issue #4789, but you closed it with blocked status without any discussion.

Also, keep #4534 in mind: TSLint is in the process being deprecated.

Yes, maybe TSLint team will stop deprecate existing rules? False positive result is not a reason for removing rule. By this logic any buggy rule can be removed.

Posting again here: the rule seems to have some buggy behavior, such as the false positive mentioned in #2551. If you'd like the rule to be un-deprecated despite that (maybe the bug doesn't exist? maybe it's worth it to keep the rule?

So, example from issue #2551 is not isolated and contains some project specific entities.

I tried to test code from replies:
#2551 (comment)
#2551 (comment)

There are no errors with no-use-before-declare rule and latest version of tslint.

[JoshuaKGoldberg]

Come on. I created new issue #4789, but you closed it with blocked status without any discussion.

Oh oops, sorry! I did a dumb and thought it was a PR. That is entirely my fault; will re-open.