Is this all necessary? Can we not just add both the action and browserAction versions to the array?

Should we be using cfg().desktop.mv3 and code fencing to avoid dealing with the envs directly?

Sure, but just to confirm do you mean code fencing just the import cfg from './desktop/utils/config'; or the whole if as well?

Good point, probably not worth it here as you'd have to break up the condition and it'd get ugly.

We can remove configOverride if it's no longer being used.

Is there a way to fully get rid ENABLE_MV3 env variable?

For example by calling both the MV3 and the non-MV3 method in the extension?

browser.action.setBadgeText({ text: label });
browser.browserAction.setBadgeText({ text: label });

It's possible if I use fencing.

      ///: BEGIN:EXCLUDE_IN(desktopapp)
      browser.action.setBadgeText({ text: label });
      browser.action.setBadgeBackgroundColor({ color: '#037DD6' });
      ///: END:EXCLUDE_IN

It will result in errors like Cannot find browser method - browserAction.setBadgeBackgroundColor.

This isn't actually doing anything as in the desktop app (which is always MV2), we would never hit the desktopextension code fence as it has its own desktopapp build type. And in the extension itself, we can detect isManifestV3 correctly and use the alternate condition.

On reflection, the cleanest fix for this issue is to update browser-proxy in the common package which receives browser commands from the app and runs them against the real browser. Here we can use isManifestV3 as we're in the extension, and update getBrowserMethod to just update all browserAction functions to use action if we're in MV3.

Thanks @matthewwalsh0, applied the fix on browser-proxy to replace browserAction with action when the extension is in MV3.