Rewrite in TypeScript

Now that https://github.com/typescript-eslint/typescript-eslint/pull/425 has been released, it should be relatively straightforward to migrate.

I think porting one and one rule makes the most sense. Feel free to pick one 🙂

• consistent-test-it - #327
• expect-expect - #325
• lowercase-name - #258
• no-alias-methods
• no-commented-out-tests - #305
• no-disabled-tests - #315
• no-duplicate-hooks - #318
• no-empty-title
• no-export - #323
• no-focused-tests - #314
• no-hooks - #322
• no-identical-title
• no-if - #324
• no-jasmine-globals - #315
• no-jest-import - #259
• no-large-snapshots
• no-mocks-import - #309
• no-test-callback - #321
• no-test-prefixes - #328
• no-test-return-statement - #320
• no-truthy-falsy
• prefer-called-with
• prefer-expect-assertions
• prefer-inline-snapshots - #319
• prefer-spy-on - #326
• prefer-strict-equal - #329
• prefer-to-be-null
• prefer-to-be-undefined
• prefer-to-contain
• prefer-to-have-length
• prefer-todo - #335
• require-tothrow-message
• valid-describe - #308
• valid-expect-in-promise
• valid-expect - #333

[G-Rath]

@SimenB Just wanted to let you know I’ve not forgotten about this 😉

I’ve got 2 rules left to convert, and the new guards + expect parser is working a treat.

Life got a bit busy once I got back, but I hope to have a PR for review by midweek.

As an example of how nice the new expect stuff is: prefer-to-be-null & prefer-to-be-undefined took literally 5 minutes to convert, despite being the two rules that used those massive expect guards, as they were having to account for not.

Now they’re just:

const isNullEqualityMatcher = (
  matcher: ParsedExpectMatcher,
): matcher is ParsedNullEqualityMatcher =>
  EqualityMatcher.hasOwnProperty(matcher.name) &&
  matcher.node.parent !== undefined &&
  matcher.node.parent.type === AST_NODE_TYPES.CallExpression &&
  hasOneArgument(matcher.node.parent) &&
  isNullLiteral(matcher.node.parent.arguments[0]);

/* in create: */
if (!isExpectCall(node)) {
  return;
}

const { matcher } = parseExpectCall(node);

if (matcher && isNullEqualityMatcher(matcher)) {
  context.report({
    fix(fixer) {
      return [
        fixer.replaceText(matcher.node.property, 'toBeNull'),
        fixer.remove(matcher.node.parent.arguments[0]),
      ];
    },
    messageId: 'useToBeNull',
    node: matcher.node.property,
  });
}

[SimenB]

I don’t know enough about the eslint ecosystem to know if its worth using the @typescript-eslint/parser over the current one, which is now my question - what is the advantage?

We don’t want to use the parser in our own rules - we want to use the utils which provide way better types than the ones from DefinitelyTyped as well as some nice utils for options etc. It’s also stricter (also called opinionated 😛), forcing us to follow some good conventions (fixing both #201 and #202 at once).

We do however want to use the parser for linting our own code, but that should not be visible to consumers.

---

The dependency on typescript was not on purpose, see https://github.com/typescript-eslint/typescript-eslint/pull/425#issuecomment-498302492

When a release is out, we can probably retry this (I’ll revert my earlier revert). Will need to dig into #268 as well at that point.