Description

This PR fixes a bug where pattern exclusion with\! (negation) wasn't working correctly for new (non-exported) components.

Problem

Pattern exclusion was broken for new components that haven't been exported yet. Even when using the full component ID with scope, the exclusion didn't work. For example:

• Pattern\!scope/comp1 should exclude the component, but it didn't
• Pattern**, \!scope/comp1 should match all except comp1, but comp1 was still included

The root cause was specific to new components:

• For new components,legacyId.toString() returns justcomp1 (without scope)
• Butid.toStringWithoutVersion() returnsscope/comp1 (with scope)
• The pattern matching was passing both formats['comp1', 'scope/comp1'] to multimatch
• When the exclusion pattern\!scope/comp1 was applied, it excludedscope/comp1 but NOTcomp1
• Sincecomp1 wasn't excluded, multimatch returned it, and the component was incorrectly included

Note: For exported components, both IDs include the scope, so the exclusion worked correctly.

Solution

The fix removes the legacy ID format from pattern matching, using only the harmony ID format (with scope) consistently for all components. This ensures exclusion patterns work correctly for both new and exported components.

Implementation

• Created an ID map from harmony ID strings to ComponentID objects
• Single multimatch call with harmony IDs only
• Map results back to ComponentIDs

This is a clean solution - just 3 lines of logic that fixes the exclusion functionality.

Testing

• Added comprehensive e2e tests for pattern exclusion with new components
• Tests cover both basic exclusion patterns and full component ID exclusion
• All exclusion patterns now work correctly for new components:
  • \!scope/comp1 - excludes comp1 ✓
  • **, \!scope/comp1 - matches all except comp1 ✓
  • \!**/comp1 - excludes comp1 using wildcard ✓

Breaking Change

Multiple component patterns without scope

• Previously: Patterns like"comp1, comp2, comp3" worked for new components
• Now: These patterns won't match anything (since all components have a scope)
• Users need to use either:
  • Full IDs:"scope/comp1, scope/comp2, scope/comp3"
  • Wildcards:"**/comp1, **/comp2, **/comp3"

Note: Single component patterns like"comp1" (without comma) still work regardless, because they use the workspace/scoperesolveComponentId method instead of multimatch.

Trade-off (not a breaking change)

Single component patterns without scope

• Patterns like\!comp1 (without scope) still don't work (this didn't work before either)
• Users need to use either:
  • Full ID:\!scope/comp1
  • Wildcard:\!**/comp1

Why this is actually better

• More consistent and predictable behavior
• Clearer intent - explicitly specify scope or use wildcards
• Eliminates ambiguity between components with same name in different scopes