R019: .key重复

Detect duplicate `.key()` string literals across `.ets`, `.ts`, and `.js` files in XTS projects.

31|6|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill r019-key
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: R019: .key重复
Source: https://github.com/openharmonyinsight/openharmony-skills/tree/main/skills/check-test-code-quality/rules/R019
Command: npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill r019-key

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents UI state and component identity issues by ensuring that .key() string literals are unique across all source files inside the same independent XTS project.

Core Features & Use Cases

  • Detect duplicate .key('...') string literals across recursively collected .ets, .ts, and .js files within each independent XTS project.
  • Group duplicates and report once per duplicate group, using the first occurrence location while listing other locations in the suggestion.
  • Avoid false positives by ignoring non-string .key(...) arguments and empty-string keys, and by not comparing keys across different independent projects.

Example use case: You maintain an ArkTS/XTS UI test suite where multiple pages accidentally reuse the same .key('customPropertyValue') across different test files; this Skill identifies every duplicated key within the project so you can rename them to stable unique identifiers.

Quick Start

Use this skill to scan an independent XTS project directory for duplicated .key('...') values and return a single consolidated issue per duplicated key group.

Frequently Asked Questions about R019: .key重复

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect duplicate .key values in an ArkTS XTS UI test project?

Duplicate .key values cause UI state and component identity collisions in XTS projects. Scanning for repeated .key() string literals across source files identifies these conflicts so you can rename them to stable unique identifiers and restore UI test stability.

Does duplicate key scanning compare .key string literals across different XTS projects?

Duplicate key scanning filters false positives by ignoring non-string arguments and empty-string keys. It extracts only valid .key() string literals from .ets, .ts, and .js files, ensuring that only actual duplicate non-empty keys are grouped and reported.

What is the best way to find reused .key custom property values in a UI test codebase?

The best way to find reused .key custom property values is to run a project-level validation scan that recursively collects source files and extracts .key() literals. This groups all duplicate string instances and reports one consolidated issue per duplicated key group.

How are duplicate .key occurrences grouped and reported in static analysis results?

In static analysis results, duplicate .key occurrences are grouped by matching string literals and reported once per duplicate group. The report uses the first occurrence location as the primary issue anchor while listing other collision locations in the suggestion.