• Performance | apps/oxlint/src-js/plugins/visitor.ts:467-527
mergeVisitFns() sorts visitProps in-place. These arrays come from compilingLeafVisitor[typeId] / compilingNonLeafVisitor[...] and are then cleared (visitProps.length = 0). That’s OK, but it means every finalize pays an O(n log n) sort cost per active node type.

Given this is a hot path for linter execution, it’s worth sanity-checking whether sorting is required for all multi-visitor cases. Many node types likely only have one handler (common case) and you already fast-path numVisitFns === 1.

For the multi-handler case, you may be able to avoid full sorts by inserting VisitProps in sorted order at add-time (stable insertion) or by bucketing by (attributeCount, identifierCount) when selector parsing already computes counts.

• Readability | apps/oxlint/src-js/plugins/visitor.ts:214-214
VisitProp pooling resets only fn and selectorStr to null, but leaves attributeCount / identifierCount intact. That’s fine because you overwrite them when reusing from cache.

The issue is the rare path called out in the comment: selectors with typeIds empty cause visitProp to be allocated/claimed from the pool and then never stored into any per-type list. In that case, the object remains “in use” until finalizeCompiledVisitor() when you clear visitPropsCacheNextIndex back to 0—but its fn/selectorStr will still be nulled because your reset loop runs for (i = visitPropsCacheNextIndex - 1; i >= 0; i--).

That’s correct, but it relies on always calling finalizeCompiledVisitor() even if compilation throws later in the same visitor. If an exception is thrown after some visitProps are checked out, the cache index won’t reset and subsequent compilations may reuse partially-initialized objects or leak references longer than intended.

• Maintainability | apps/oxlint/src-js/plugins/visitor.ts:270-270
VisitProp instances are shared across all typeIds for selectors like :matches(A, B) (same object pushed into multiple per-type arrays). mergeVisitFns() sorts the per-type VisitProp[] in place, which is fine, but it also mutates visitProps.length = 0 at the end. Because those arrays are per-type, that part is fine too.

The risky part is the shared VisitProp object itself: it’s mutated later for complex selectors (visitProp.fn = wrapVisitFnWithSelectorMatch(...)) and for specificity (attributeCount |= ..., identifierCount = ...). Right now that mutation occurs before the object is pushed to per-type arrays, so it’s consistent.

However, this design becomes fragile if any future change mutates a VisitProp after it’s been added to one type’s array (e.g. a later pass sets a tie-breaker, a late wrap, etc.). Given how subtle this is, it deserves a hard guard or an explicit comment stating that VisitProp is immutable after insertion.

What changed

apps/oxlint/src-js/plugins/visitor.ts

• Expanded visitor-key support to include selectors (not just node type names) and updated documentation/examples accordingly.
• Reworked visitor compilation to collect VisitProp records (fn, attributeCount, identifierCount, selectorStr) per node type, and to sort visitor invocations by selector specificity to match ESLint semantics.
• Introduced:
  • VisitProp object pooling (visitPropsCache) and persistent per-type buckets (compilingLeafVisitor, compilingNonLeafVisitor) to reduce allocations.
  • EXIT_FLAG embedded into attributeCount to ensure exit callbacks sort after enter callbacks for leaf nodes.
  • Active type tracking via activeLeafVisitorTypeIds and activeNonLeafVisitorTypeIds.
• Updated finalizeCompiledVisitor() to merge sorted visitor arrays into compiledVisitor, reusing cached {enter, exit} objects.

Test fixtures

• Updated selector fixture plugin to use "*:exit" instead of "Program:exit" for reporting.
• Updated selector snapshot ordering to reflect the new specificity-based visitor execution order.