Closed G-Rath closed 2 months ago
@SimenB I know you had opinions about including these in the past - would appreciate knowing if those have changed
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.
@dangreenisrael are you happy for this to happen?
@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.
Deprecating on npm is probably enough as people installing would get a warning. Which might be a bit heavy handed of course 😅
@G-Rath was this PR abandoned?
@lasersio2 nope, just waiting to hear back from the owner :)
@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 🤔
Yeah, that seems reasonable to me
Ok so to recap some high level points before this lands:
The two notable things for end users are probably:
parseJestFnCall
, among other things meaning it technically doesn't respect the globalAliases
or globalPackage
settings
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 lintThe 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.
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. 🙂
a separate config seems fine, but without overrides
like you mention
Wouldn't that just be adding the rule padding-around-all
? What else would there be in the recommended config?
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
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. 🙇
:tada: This issue has been resolved in version 28.8.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
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
Resolves #1301 Resolves #1251 Resolves #113 Resolves #17