We agreed on an approach for code intel that leaves all call sites unchanged and uses a proxy to hijack the code intel related APIs on the extensions controller.
We previously, however, made a change so that the extensions controller is null when the legacy extension system is disabled. Since the migrated code intel APIs depend on it, we have to revisit this decision.
Now, instead of setting the controller to null, we create a new no-op controller that has all API methods mocked out and return either null, an empty array, or another placeholder value. For getting code intel APIs to work, we can still use a proxy over this object and only implement the APIs we want to while making sure no other extension specific code is pulled in.
Since the existing Controller interface was exposing comlink APIs (specifically the Remote<> interface), we have to do a bit of mocking so that the no-op controller also appears to have a remote comlink object when in fact it doesn't.
I decided to keep the nullability in the Controller prop types to make it clear for other developers that they can no longer depend on these APIs being there.
As a next step we should revert this change and inject the new code intel APIs directly into the callsites. This is a risky processes and since we want to finish this up for a release candidate by next week, we'll likely follow up with this after the release.
I also force-disabled a couple of extension related features by checking the value of the enableLegacyExtensions flag directly. This helps us make sure the impact of these changes are smaller and we don't continue to load features like e.g. the command pallet.
Test plan
Code still loads:
Adding console.error statements in the remote proxy shows that code intel related APIs are still being called:
