Catch dependencies of functions used before assignment

[OliverJAsh]

    foo()
    const x = 1;
    function foo() { x; }

or

const foo = () => x;
foo();
const x = 1;

This will produce a ReferenceError. Should TypeScript be catching this? foo can be called before its dependencies have been defined.

[mohsen1]

I don't think TS can track that. For instance this is valid code:

  foo()
    const x = 1;
    function foo() { typeof x; }

[aluanhaddad]

@mohsen1 your example throws on node 7, and in the current versions of Chrome, Edge, Firefox, and Opera, with Firefox giving the most precise error
ReferenceError: can't access lexical declaration 'x' before initialization

@OliverJAsh I was going to recommend the tslint rule no-use-before-declare, but it does not catch this either.

[DanielRosenwasser]

@aluanhaddad correct - the code itself has to be executed before you get the error. The following won't error unless you actually call f.

function f() {
    foo()
    const x = 1;
    function foo() { typeof x; }
}

In other words, the error isn't what ECMAScript calls an early error - it's not given by analyzing the code structure. It's an error caused by actually executing the code.

[aluanhaddad]

@DanielRosenwasser Yeah, the code I was actually testing with was

(function () {
    foo();
    const x = 1;
    function foo() { x; }
}())

The difference is interesting since the reference to foo is perfectly valid and the capture of x is also perfectly valid but the error arises from when the call to foo is made relative to the initialization of x.

[aluanhaddad]

I think that suggests it actually should not be an error since

(function () {
    try {
        foo();
    } catch (e) {
        console.error(e);
    }
    const x = 1;
    function foo() { console.log(x); };
    foo();
}());

is valid.

[OliverJAsh]

ESLint's no-use-before-define rule catches this. Perhaps it should live in tslint, as I suggested at palantir/tslint#1537

[rotemdan]

Bear in mind that any rule that's added to TSLint might in practice get drowned by hundreds of warnings about missing semicolons and braces etc., especially in a large project. I personally don't feel combining messages about coding conventions and the identification of actual potential software bugs to be a great idea.

[mohsen1]

Actually linting is more about catching common runtime errors that are impossible or hard to find at compile time.

[aluanhaddad]

@OliverJAsh Thank you for opening that issue with tslint. I always use this rule and wish it caught this.

Bear in mind that any rule that's added to TSLint might in practice get drowned by hundreds of warnings about missing semicolons and braces etc., especially in a large project. I personally don't feel combining messages about coding conventions and the identification of actual potential software bugs to be a great idea.

The key thing is to agree on a convention with your team. This can be very difficult to do but it is worthwhile. Then clean up your code. There might be a few commits that have a deceptively large scope but it's worth it. If people don't bother to lint the code before they check it in, then get a broom and sweep up behind them 😄 . Even better would be to use a pre-commit hook but some people will be very frustrated if you do that.