@@ -176,8 +176,18 @@ exports.queries = {
176176 /:left/:property/:name == "version"
177177 ]/$:right/:init/:value
178178 ` ,
179+ /*
180+ //:left matches the .left of any node with that attribute (also
181+ BinaryExpression, LogicalExpression, etc, not just AssignmentExpression),
182+ so this scans far more candidates than necessary on every CallExpression
183+ in the file (this query's anchor). Narrowing to an explicit
184+ AssignmentExpression[...] type filter lets the engine use its type index
185+ instead of a same-attribute scan across unrelated node types — same
186+ matches, measurably cheaper on every file scanned, no version-specific
187+ structural assumptions added.
188+ */
179189 `//CallExpression[
180- /:callee//:left/:property/:name == "Vue"
190+ /:callee//AssignmentExpression[/ :left/:property/:name == "Vue"]
181191 ]/:arguments//AssignmentExpression[
182192 /:left/:property/:name == "version"
183193 ]/$$:right/:value` ,
@@ -192,8 +202,15 @@ exports.queries = {
192202 2.x/3.0.x: var DOMPurify = function DOMPurify(root){...}
193203 3.1.x+: const DOMPurify = root => createDOMPurify(root)
194204 */
205+ /*
206+ Narrowed from //:left (matches any node with a .left attribute — also
207+ BinaryExpression, LogicalExpression, etc) to an explicit
208+ AssignmentExpression type filter: same matches, but lets the engine use
209+ its type index instead of scanning every attribute-bearing node type on
210+ each of the many CallExpressions in a file (this query's anchor).
211+ */
195212 `//CallExpression[
196- /:callee//:left/:property/:name == "DOMPurify"
213+ /:callee//AssignmentExpression[/ :left/:property/:name == "DOMPurify"]
197214 ]/:arguments//AssignmentExpression[
198215 /:left/:property/:name == "version"
199216 ]/:right/:value` ,
0 commit comments