Which migration strategy best preserves Protractor-specific locators?

The short answer: no successor framework — Playwright, Cypress, or WebdriverIO — supports by.model(), by.binding(), or by.repeater() natively, and there is no standardized translation table. The strategy that best preserves the intent of those locators is not translation at all: it is instrumenting the Angular application with stable data-test (or data-testid) attributes before or during the migration, then rewriting selectors against those attributes.

Why direct translation fails

Protractor locators query Angular's internal scope and digest state, not the DOM. Two of them have partial DOM footprints you can exploit as a stopgap:

• by.binding('user.name') often corresponds to elements carrying ng-bind="user.name" or the ng-binding class, so [ng-bind="user.name"] is a workable CSS approximation in AngularJS-era templates.
• by.repeater('item in items') can sometimes be approximated with [ng-repeat="item in items"].

But by.model() maps to ng-model only in AngularJS (1.x); in Angular 2+ there is no reliable DOM trace of the bound property at all. Interpolation bindings ({{ user.name }}) also leave no queryable attribute. Any strategy built on scraping these artifacts is fragile and version-dependent — treat it as a bridge, not a target.

The recommended strategy: test IDs as a migration prerequisite

1. Add data-test="..." attributes to the templates your suite touches. Name them after the component role, not the binding expression.
2. Measure coverage before rewriting: grep -r "data-test" src/ | wc -l against your list of Protractor locator usages tells you how much instrumentation remains.
3. Rewrite each Protractor locator to the framework's test-id mechanism — Playwright's page.getByTestId(), or [data-test="..."] selectors in Cypress/WebdriverIO.
4. Only where instrumentation is impractical (third-party components, generated markup), fall back to the ng-binding/ng-repeat approximations above, and flag those tests for later hardening.

This costs template changes, which is the real objection — but it is a one-time investment that decouples tests from both the framework and Angular internals, which is exactly what Protractor locators failed to do.

Synchronization: which framework comes closest

Protractor's automatic wait-for-Angular has no true equivalent. The honest comparison:

• Cypress is the closest in practice. Its automatic retry-ability of commands absorbs most timing issues, and the community plugin cypress-angular-selectors mimics by.model/by.binding semantics. Caveat: it is unofficial, targets specific Angular versions, and should be treated as transitional.
• Playwright waits on element/actionability states and network activity, not the digest cycle. It is the stronger long-term framework, but you own synchronization via explicit waits or route mocking.
• WebdriverIO with an Angular-aware service can access debug elements, but setup is heavier and equally unofficial.

Verification before committing

Because community plugins and Angular internals change across versions, validate on your stack: run a pilot of 10–20 representative specs in staging, and include at least one flow with asynchronous HTTP-driven binding updates — that is where synchronization differences surface. If timing flakes appear only under load, the issue is synchronization strategy, not selector choice.

Version note: plugin compatibility and framework waiting behavior described here should be re-verified against the current releases of your chosen framework before rollout.