Replies: 2 comments 1 reply
-
Hello @ad-m I think this is a good idea! Thanks for sharing. I am moving this issue to discussions as we are looking to use the Github issues for true bugs only. |
Beta Was this translation helpful? Give feedback.
1 reply
-
The question that we have to answer is whether we forbid anything else to be referenced by "React". It is worth taking a look at the imports:
And references too:
It looks |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Is your feature request related to a problem? Please describe.
I would like to ask about the governance process for linting rules.
I received the comment:
Originally posted by @geido in #18200 (comment)
Linting rules are often a sore point or at least a subjective feeling. Are there general rules for managing eslint rules in a project that I should follow when proposing changes?
We do not import that consistently in project, for example:
superset/superset-frontend/src/components/IndeterminateCheckbox/index.tsx
Line 85 in 076f774
superset/superset-frontend/src/components/Icons/Icon.tsx
Line 20 in 99d15b2
I would like to propose that the above-mentioned suggestion was presented as a linting rule and enforced.
Describe the solution you'd like
I have developed a suitable linter:
You can check it at https://astexplorer.net/ .
Describe alternatives you've considered
Alternative
no-restricted-syntax
(seehttps://eslint.org/docs/developer-guide/selectors ) can be configured to avoid import, but it will reduce the precision of the error message.
We might also do not introduce any linting rules, but it will increase a maintainer burden to communicate & validate that rules manually.
Additional context
Beta Was this translation helpful? Give feedback.
All reactions