Should not report an error on "null" when using in type position

[yuit]

We are trying to add linting to our library source files and run into issue below.

Bug Report (delete this for feature requests)

• TSLint version: @next
• TypeScript version: latest source-code built in master branch
• Running TSLint via: Node.js API

TypeScript code being linted

match(regexp: string): RegExpMatchArray | null;

with tslint.json:

     ....
     "no-null-keyword": true,

Actual behavior

Get an error Use 'undefined' instead of 'null'

Expected behavior

There shouldn't be an error when using null in type position

[jkillian]

Good catch, null should be allowed as a type

[adidahiya]

specifically, this has to do with the no-null-keyword rule

[jkillian]

Two quick questions @yuit:

• Do you know an easy way when dealing with the AST to tell if a node is being used as a type?
• Does TS produce the same AST no matter if the --strictNullChecks flag is on or not?

[jkillian]

Okay, as far as I understand from this, no matter what the compiler options, null is still allowed in a type position. So, TSLint should be able to disregard whether --strictNullChecks is being used by the end user which is very good.

So question two from above taken care of I think 😃

[jkillian]

As for my first question, although a little different than the top-down approach TSLint normally uses, seemed easiest to just traverse through the ancestors of each found null keyword and check if any ancestor has a type kind. Theoretically this could be re-traversing a lot of nodes, but in this context the issue shouldn't arise.

[yuit]

@jkillian I agree to check that null is used in type position. you will have to walk up the parents to check if any has a type kind. However, as you mentions it shouldn't be too much performance hit since the level of traversing shouldn't be too deep

[jkillian]

Great, fix is merged! This will be in a release shortly