Allow localdev server to run with Locker Service to prevent release bugs.

[erocheleau]

Is your feature request related to a problem? Please describe.
While using the localdev server, we've realized that there are some differences between what we can do in the localdev and what we can actually do once the code is deployed and running either in an Experience Cloud site or the Lightning Experience Console. Namely for instance, it looks like Locker (maybe?) enforces the shadowDOM to be closed for lightning- namespaced components.

One precise example of what we ran through was that we used a lightning-formatted-rich-text component in our application. Within the localdev server we could use the HTML innerText property on this element to retrieve the value of what was rendered by the lightning-formatted-rich-text. But while in a context where Locker is active, innerText just returns undefined because we can't peek in the DOM of the lightning- component.

Describe the solution you'd like
It would make it easier to make sure our developed components are compatible with Locker if there was a way to run Locker within the localdev server, perhaps with a parameter during execution?

Describe alternatives you've considered
For now the localdev is still very valuable, it allows us to iterate really quickly on our components. But we still need to create a scratch org, sometimes create a community/a console app to deploy our components in order to test them before merge so we can be sure they will actually work. It makes the process longer than it has to be and can lead to errors with newer engineers who do not know the details of Locker yet.

Additional context
Nothing. Thanks for this amazing feature!

[AllanOricil]

This is a must. Yesterday I found a bug caused by the locker service when running the component on a sandbox.