Generalize Mocha rules to all testing frameworks

[JoshuaKGoldberg]

These rules should be renamed (maybe replace "mocha" with "test"?) and changed so that any Mocha-specific API names are configurable to allow any test framework. For example, Jest allows xdescribe in addition to describe.

• mocha-avoid-only
• mocha-no-side-effect-code
• mocha-unneeded-done

Following up on #453.

[astorije]

As we are transitioning from Mocha to Jest, and we weren't sure if you would integrate Jest-specific rules, I was considering creating a new package for those, but that would be great too!

However, I wonder how much this be made generic. For example, while #453 adds exceptions for Mocha, that would not apply to Jest. Similarly, Mocha recommends against using arrow functions (which has led to a Mocha-aware prefer-arrow-callback rule in the ESLint world) while Jest doesn't.
What were you thinking of in terms of implementation? On one hand, I'm afraid making these rules generic would mean moving the logic to the consumer (which isn't too great), but on the other hand, making these rule aware of the framework they're linting against means this repo has to contain logic specific to Mocha, Jest, and potentially others.

[JoshuaKGoldberg]

One concerning point about splitting into new packages is the added maintenance overhead. We could...

• ...switch to a monorepo, which is more work to maintain and an an additional barrier to entry for newcomers?
• ...create some unified configuration package all repos use, like create-react-app?
• ...put the cost of maintenance on each package?

Perhaps we should have recommended rulesets per test framework with just the test-specific rules? The tslint-microsoft-contrib/mocha (or however TSLint prefers namespaces) preset could contain, for example the Mocha names for describe; tslint-microsoft-contrib/jest could contain Jest's, and so on.

[reduckted]

Maybe you could do something similar to what I have set up at work. It's like the recommended rulesets that you mentioned. We have a standard tslint config that we use on all projects. That config is published on our internal npm registry, and the "main" file of the package points to a tslint config file, so the bare minimum tslint config would look something like this:

{ 
    "extends": ["@company/tslint-config"]
}

That npm package also contains additional rulesets that are specific to certain types of projects. So, for example, if the project was something that would run in the browser, then you'd have a config that looks like this:

{ 
    "extends": [
        "@company/tslint-config",
        "@company/tslint-config/rulesets/browser"
    ]
}

And there's also a ruleset for unit tests that you would use in a tslint.json file in the tests directory. That config in the tests directory typically ends up looking like this:

{ 
    "extends": [
        "../tslint.json",
        "@company/tslint-config/rulesets/testing"
    ]
}

Using that same concept, maybe you could split the rules up into categories (react, mocha, chai, jest, etc), and have a config for each category that just specifies a rulesDirectory that points to the directory for the category. So it's like the recommended rulesets per test framework, except instead of enabling rules, it just allows the rules to be used - that's not strictly required, because you could just put all of the rules in the same directory (as they are now) and only enable the ones that you want, but it makes the config a bit clearer about what you intend to use.

To allow all of that, you'd need a (published) directory structure that's something like this:

/
 |-- rules/
 |-- chai/
 |   |-- rules/
 |   |-- index.js
 |   |-- recommended.js
 | 
 |-- jest/
 |   |-- rules/
 |   |-- index.js
 |   |-- recommended.js
 | 
 |-- mocha/
 |   |-- rules/
 |   |-- index.js
 |   |-- recommended.js
 | 
 |-- react/
 |   |-- rules/
 |   |-- index.js
 |   |-- recommended.js
 | 
 |-- index.js
 |-- recommended.js

The rules directories contain the rules for that category. The index.js files are configs that only specify the rulesDirectory, and the recommended.js files are configs that enable rules.

So if you wanted to use the mocha rules (as well as the standard rules), but wanted to control which ones are enabled, you'd have a config like this:

{
    "extends": [
        "tslint-microsoft-contrib",      // Allows the base rules to be used
        "tslint-microsoft-contrib/mocha" // Allows the mocha rules to be used
    ]
}

But if you wanted to use the mocha rules and have the recommended rules enabled, then you could use a config like this:

{
    "extends": [
        "tslint-microsoft-contrib",                  // Allows the base rules to be used
        "tslint-microsoft-contrib/mocha/recommended" // Uses the recommended mocha rules
    ]
}

Thinking about it a bit more, a config for just specifying the rules directory and another for a recommended ruleset is probably overkill, but I would advocate for splitting up the rules into a directory per category (the root config just has specifies multiple rule directories), because that will make the code base easier to navigate.

[JoshuaKGoldberg]

💀 It's time! 💀

TSLint is being deprecated; therefore, it and tslint-microsoft-contrib are no longer accepting pull requests for major new changes or features. See palantir/tslint#4534. 😱

If you'd like to see this change implemented, you have two choices:

• Recommended: Check if this is available in ESLint + typescript-eslint ✅
• Not Recommended: Fork TSLint or tslint-microsoft-contrib locally 🤷‍♂️

👋 It was a pleasure open sourcing with you!

If you believe this message was posted here in error, please comment so we can re-open the issue!