This repository has been archived by the owner on Aug 20, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 18
Adding to getKeys
blocklist
#38
Labels
Comments
4 tasks
Can you expand on this? What is the user-facing impact? What is the suggested fix? |
I've amended the original message. |
Thanks! 👍 |
What exactly is |
Closing due to age. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As per the points raised in #36 by @mdjermanovic ,
getKeys
might be ignoring the following additional properties, with the items in parentheses being relative to ESLint but may call for a major version bump if considering other users:type
(perf)range
(fromBaseNodeWithoutComments
) (perf)loc
(fromSourceLocation
) (perf)comments
andinnerComments
(fromComment
) (fix since may be mistakenly traversed)User-facing impact
It is possible some custom AST could be using those properties as legitimate keys, might somehow be (ab)using
getKeys
to not expect the above properties to be excluded, or might have a traversal function which doesn't ignore those properties when iterating through them.What is the suggested fix?
However, from the perspective of ESLint, and I think reasonable expectations at least in a major bump, these shouldn't be allowed for traversal given that some are uniformly known not to need traversal given their fixed, special meaning (the
perf
-labeled items).For
comments
andinnerComments
the case is even stronger to exclude because these will be traversed if present, but as per our prior exclusion ofleadingComments
andtrailingComments
, the expectation seems to be not to traverseComment
nodes even if present.Our new tool to get keys from the TypeScript AST at least does not allow these when building our own key list (by excluding any which lead to
Line
orBlock
types), but other tools do not have access to this algorithm when usinggetKeys()
.The text was updated successfully, but these errors were encountered: