[Feature Request] Ability to add custom limits to rules #34
Replies: 3 comments
-
Hi @MikeDabrowski, Hmm, in this case, you would also need to handle each nesting within a given function/class. The example refers to fileExport, but if it's possible within the rule, it could also be nestedSelectors. In that case, it gets more complicated, and you need to additionally handle the specific nesting level. That's why I generally limited the limits to the root level of the file. |
Beta Was this translation helpful? Give feedback.
-
Okay fair point. Lets reduce the scope then. I'm actually only interested in the 'public api', so the exports. For that, the root level limits would work, but unfortunately they also check non exported variables on root level. Maybe a For 'at least' selector - similarly - I would need that for the exports only. Maybe min/max in the limits ? Do you have any ideas ? |
Beta Was this translation helpful? Give feedback.
-
Something like this sounds okay and should be relatively simple to implement. It also won’t require a major version bump for the package. I can add it with some larger changes, but it won’t be my priority. If you need this functionality right away, you can submit a PR or wait for someone from the community. Overall, I’m giving the green light to this idea. "rootSelectorsLimits": [
{ "selector": "arrowFunction", "limit": {min: 1, max: 2} },
{ "selector": ["interface", "type"], "limit": 2 }
],
"exportedSelectorsLimits": [
{ "selector": "arrowFunction", "limit": {min: 1, max: 2} },
{ "selector": ["interface", "type"], "limit": 2 }
] |
Beta Was this translation helpful? Give feedback.
-
I would like to have an option that would act similar to
rootSelectorsLimits
but working on rules rather than hardcoded to 'root' level.Example rule, that should only allow up to {limit} variables matching the pattern that are exported from the file.
Example rule that would require {at least} exported variables matching the pattern
Beta Was this translation helpful? Give feedback.
All reactions