You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 (from BaseNodeWithoutComments) (perf)
loc (from SourceLocation) (perf)
comments and innerComments (from Comment) (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 and innerComments the case is even stronger to exclude because these will be traversed if present, but as per our prior exclusion of leadingComments and trailingComments, the expectation seems to be not to traverse Comment 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 or Block types), but other tools do not have access to this algorithm when using getKeys().
The text was updated successfully, but these errors were encountered:
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: