Skip to content

Fix find-usages computed property edge case #66

@devill

Description

@devill

Problem

The find-usages command has a complex edge case when finding usages of computed property access that needs community discussion before implementation.

Current Status

Currently skipped in the test suite with reason: "Complex edge case that needs review"

The Complexity Explained

The core issue is ambiguity in what should be followed when dealing with computed property access patterns like obj[key].

Example Scenario

const key = 'propertyName';
const value = someObject[key]; // What should find-usages track here?

The Dilemma

When we encounter someObject[key], there are multiple valid interpretations:

  1. Track the variable key - The variable itself is being used
  2. Track the property access - We're accessing someObject.propertyName
  3. Track both - Both the variable and the resulting property access

Why This Is Complex

Unsafe Operation Context: Using strings as object keys makes reference tracking inherently difficult:

  • The actual property being accessed is determined at runtime
  • Static analysis can't reliably determine what property is being referenced
  • Multiple variables could contain the same string value

Reference Ambiguity: In the test case, key is a usage of a variable, but we're simultaneously accessing a property that belongs to the string value contained within key. This creates a semantic ambiguity about what the "usage" actually represents.

Safety vs Utility Tradeoff: While computed property access can be useful, it should be used cautiously precisely because it makes reference tracking harder. Banning it entirely would be overly restrictive.

Current Instinct

Based on initial analysis, the key variable usage should probably be included in find-usages results since it represents a direct usage of the symbol being tracked.

However, the broader question of how to handle computed property access patterns consistently across different scenarios needs community input.

Related Skipped Test

  • tests/fixtures/commands/find-usages/edge-cases/computed-property - Test for finding usages of computed property access
  • Command: find-usages '[computed.ts 7:7-7:10]'

Discussion Points

  1. Should we track the variable, the property access, or both?
  2. How do we handle cases where the computed key could reference multiple different properties?
  3. What are the security/safety implications of different approaches?
  4. How do other refactoring tools handle this pattern?
  5. Should we provide configuration options for different tracking behaviors?

Acceptance Criteria

  • Community discussion and consensus on approach
  • Clear specification of expected behavior for computed property access
  • Implementation based on agreed approach
  • Update test tests/fixtures/commands/find-usages/edge-cases/computed-property to pass
  • Remove skip from fixture.config.json once implemented
  • Documentation of computed property access handling in find-usages

Priority

Low - Complex edge case that needs community input before implementation. Not blocking core functionality.

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

Metadata

Metadata

Assignees

No one assigned

    Labels

    DiscussionIssues where community input is encouraged to help refine the ideaExtreme hard - delayNeeds human guidance—better not to tackle this as a first issue.bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions