Rewrite in TypeScript

[SimenB]

Now that typescript-eslint/typescript-eslint#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 - ts-migration/consistent-test-it #327
• expect-expect - ts-migration/expect-expect #325
• lowercase-name - chore: port lowercase-name to TypeScript #258
• no-alias-methods
• no-commented-out-tests - chore: convert to TS #305
• no-disabled-tests - ts-migration/convert-some-utils-functions #315
• no-duplicate-hooks - ts-migration/no-duplicate-hooks #318
• no-empty-title
• no-export - ts-migration/no-export #323
• no-focused-tests - ts-migration/no-focused-tests #314
• no-hooks - ts-migration/no-hooks #322
• no-identical-title
• no-if - ts-migration/no-if #324
• no-jasmine-globals - ts-migration/convert-some-utils-functions #315
• no-jest-import - chore: migrate no-jest-import to typescript #259
• no-large-snapshots
• no-mocks-import - ts-migration/no-mocks-import-2 #309
• no-test-callback - ts-migration/no-test-callbacks #321
• no-test-prefixes - ts-migration/no-test-prefixes #328
• no-test-return-statement - ts-migration/no-test-return-statement #320
• no-truthy-falsy
• prefer-called-with
• prefer-expect-assertions
• prefer-inline-snapshots - ts-migration/prefer-inline-snapshots #319
• prefer-spy-on - ts-migration/prefer-spy-on #326
• prefer-strict-equal - ts-migration/prefer-strict-equals #329
• prefer-to-be-null
• prefer-to-be-undefined
• prefer-to-contain
• prefer-to-have-length
• prefer-todo - ts-migration/prefer-todo #335
• require-tothrow-message
• valid-describe - chore: migrate valid-describe to ts #308
• valid-expect-in-promise
• valid-expect - WIP: ts-migration/valid-expect #333

[G-Rath]

I've done a first pass of no-mocks-import, which passes all the tests.

So far, it seems to me like this'll be a bit teeth pully, as ts-estree doesn't provide you with lots of nice type guards like TS does - as a result, I've started to make my own in tsUtils, but am trying to be conservative for now, since I don't know ts-estree well enough to predict how wild things might get.

I've also encapsulated the actual primary condition into a isMockImportLiteral function - let me know if you're happy with how I've done that; I've never worked in the FB/jest domain, so I don't know what you guys prefer for coding in general 😂

Finally, off the bat there's already room for improvement, which ties in to everything I've said so far: right now the rule is only checking actual string literals, which means template strings already won't work right off the bat (regardless of if they've got actual embedded expressions or not)

This could be improved to support them w/o expressions, but you could also take this further to try and provide basic support for expressions, since you might be able to do a basic search of surrounding nodes in an attempt to see if the expression is a constant, and if it is evaluate its value.

All in all, for now I've opted for doing the basics, w/ the idea that people can fill issues requesting improvements, just to keep things simple.

I've not made a PR since I saw your previous PRs were reverted following some breaking of peoples builds. Let me know if you're still wanting to go ahead with converting to TS.

For now I'm going to continue trying to pick off the easy rules - let me know any thoughts you have :)

[jeysal]

@G-Rath thanks for investing time in this! What you've described sounds fine to me. @SimenB will probably want to kick off a second attempt at TS migration at a less busy time

[SimenB]

Thanks @G-Rath! Yeah, it seems using the module from typescript-eslint/typescript-eslint#425 requires consumers to use typescript as well, so I need to figure out how we can author rules in TS without consumers noticing at all. I'll try to get to this, but I'm still swamped at work... Feel free to dig into it if you don't mind!

[G-Rath]

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?

I'm happy to help write TS, regardless of what it's for, but yeah I think the decision that needs to be made is about converting to TS vs switching to the @typescript-eslint/parser.

The former could be started on right now if you wanted, but as you've found out the latter is a breaking change, and thus comes down to pros vs cons which I obviously can't decide for you :)

[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 typescript-eslint/typescript-eslint#425 (comment)

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.

[Mark1626]

@SimenB I'll pick up a rule, can you tell me where code migrated to typescript is maintained.

[SimenB]

A new try is up here: #305.

@M4rk9696 thanks! A PR to that branch (reapply-ts) is most welcome. Or if I'm able to land it, to master

[SimenB]

@G-Rath would you be able to PR no-mocks-import to the reapply-ts branch of this repo? 🙂

[G-Rath]

@SimenB I can but try ;P

Give me a few minutes (or an hour, depending on the work - I've not actually been following the activity 😬)