feat: import formatting rules from `eslint-plugin-jest-formatting`

[G-Rath]

This explores what it would be like to import the formatting rules from eslint-plugin-jest-formatting - I'm a big fan of these rules and have always thought it would make sense to include them as I don't think this is a particularly controversial style.

Related: https://github.com/dangreenisrael/eslint-plugin-jest-formatting/issues/122

[G-Rath]

@SimenB I know you had opinions about including these in the past - would appreciate knowing if those have changed

[G-Rath]

Note that for now I've focused on integrating the rules into our plugin with as minimal changes as possible - there's a few things I'd like to explore refactoring, but I've not found anything actually horribly broken so I think it's better to leave such refactors for a follow-up (or at least for after confirming we want to land this); likewise for adding any new configs.

[G-Rath]

@dangreenisrael are you happy for this to happen?

[benkimpel]

@dangreenisrael are you happy for this to happen?

@G-Rath I can't really speak for @dangreenisrael, but I'm a contributor on the repo in question and I think the best place for this plugin is probably within the Jest community org now that @SimenB has relaxed the rules around style plugins a bit.

Assuming Dan wants to donate the package, we'd want to put some kind of notice on the current repo/package to say that the plugin has been adopted by the Jest community. Are there any other changes on Dan's side that would need to happen? I think the current plugin is included in some packages that bundle several plugins together, so we might have to track those down.

[SimenB]

Deprecating on npm is probably enough as people installing would get a warning. Which might be a bit heavy handed of course 😅

[lasersio2]

@G-Rath was this PR abandoned?

[G-Rath]

@lasersio2 nope, just waiting to hear back from the owner :)

[G-Rath]

@SimenB just thinking about us doing a new major, given that @dangreenisrael seems to very quiet these days, how would you feel about us landing this without him having posted a "go ahead" on this particular PR? I feel like we're all pretty happy with this move in spirit 🤔

[SimenB]

Yeah, that seems reasonable to me

[G-Rath]

Ok so to recap some high level points before this lands:

• these have been ported from https://github.com/dangreenisrael/eslint-plugin-jest-formatting
• I've converted each rule to a dedicated file, and rewritten everything into TypeScript
• I've updated the tests and code to get 100% code coverage
• I've made basic refactors to address deprecations, and removed unneeded checks

The two notable things for end users are probably:

1. this sits out of band of parseJestFnCall, among other things meaning it technically doesn't respect the globalAliases or globalPackage settings
   • I looked at this initially but found it too hard for now because the way these rules work seems to be very different (iirc, it's a lot more token based than AST based); however, for the same reason I actually don't think this'll be as big of a deal..?
   • (either way, this'll be something I look back into at a later date)
2. I've not ported over the configs, and have no plans to at this time
   • notably because the configs use overrides which I don't think is appropriate for a plugin-provided config, as we have no idea what patterns developers are using for files that are appropriate for us to lint
   • and because I don't think it's much work to just configure the rules yourself

The rule configuration to use for recommended would be:

{
  plugins: ['jest'],
  rules: {
    'jest/padding-around-after-all-blocks': 'error',
    'jest/padding-around-after-each-blocks': 'error',
    'jest/padding-around-before-all-blocks': 'error',
    'jest/padding-around-before-each-blocks': 'error',
    'jest/padding-around-describe-blocks': 'error',
    'jest/padding-around-test-blocks': 'error'
  }
}

I'll aim to do some followup documentation updates after this is landed probably in the form of a light migration guide which'll cover this.

[SchroederSteffen]

2. I've not ported over the configs, and have no plans to at this time

   • and because I don't think it's much work to just configure the rules yourself

The rule configuration to use for recommended would be: ...

Personally, I very much prefer extending the recommended (or here e.g. a recommended-formatting) config over listing the rules myself. I'd like to request adding such a config for the formatting rules if possible. 🙂

[SimenB]

a separate config seems fine, but without overrides like you mention

[alfaproject]

Wouldn't that just be adding the rule padding-around-all? What else would there be in the recommended config?

[G-Rath]

Wouldn't that just be adding the rule padding-around-all? What else would there be in the recommended config?

My understanding is that rule is more aggressive, which is why it's enabled by the strict config whereas the rules I posted above is what's in the recommended

I very much prefer extending the recommended (or here e.g. a recommended-formatting) config over listing the rules myself

I mean, I figured it wasn't a big deal because it's only a few lines, shared config etc, and like we've got a bunch of cool rules that are not enabled in our configs that you would be missing out on if you only used configs, but I don't mind shipping a config since someone actually asked for it 😄

(the practical reason I didn't include it by default is once we have a config, it's a breaking change to do anything with it - so these days I prefer to do as little as possible and then add stuff when people ask for it)

I'll do a dedicated PR for the config so it can have its own changelog, and that'll give us a version where we can double smoketest that the rules are working fine before we officially start recommending them in our docs too - I'm thinking I'll just name the config formatting

[SchroederSteffen]

I very much prefer extending the recommended (or here e.g. a recommended-formatting) config over listing the rules myself

I mean, I figured it wasn't a big deal because it's only a few lines, shared config etc, and like we've got a bunch of cool rules that are not enabled in our configs that you would be missing out on if you only used configs, but I don't mind shipping a config since someone actually asked for it 😄

Yeah, we often enable several rules in addition to shipped recommended configs. However, many times the presets are just fine and our own config is clearer and easier to maintain when using them.

Many thanks for adding it. 🙇

[github-actions[bot]]

:tada: This issue has been resolved in version 28.8.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: