Switch fluentui-react-native to pnpm mode

[JasonVMo]

Platforms Impacted

• all

Description of changes

This moves the repo to use pnpm as the nodeLinker setting for yarn. Most of the work was done at the end of the summer but appium failed to run correctly. The parts of the change are:

• reapply the fixes for jest configs and podfiles
• update appium/wdio to the latest versions
• fix type errors in apps/e2e caused by the latest types becoming stricter
• fix launching errors due to appium not finding drivers. These are fixed via installing them to the .appium directory via the APPIUM_HOME environment variable, then launching the tests with that same environment variable.
• added .appium to .gitignore
• patch the expect-webdriverio package to avoid errors about rewriting properties due to multiple versions being loaded. I'll look at removing the patch later.

Verification

Will be monitoring the pipelines to ensure they run correctly.

[Saadnajmi]

non blocking comment, how do we feel about having the webdriverio tests in FURN at all? I think the main usefulness from those tests may have now moved to our internal tests, and in FURN it feels like we've spent more time keeping them alive than not.

Some more context: one day I'd love to move Fluent Tester to use React Native Storybook, which would then use it's own testing suite and/or not use Appium. Have lots of ideas like this I'll probably never do though :)

[samuelfreiberg]

non blocking comment, how do we feel about having the webdriverio tests in FURN at all? I think the main usefulness from those tests may have now moved to our internal tests, and in FURN it feels like we've spent more time keeping them alive than not.

Some more context: one day I'd love to move Fluent Tester to use React Native Storybook, which would then use it's own testing suite and/or not use Appium. Have lots of ideas like this I'll probably never do though :)

Mind expanding a bit on this? "I think the main usefulness from those tests may have now moved to our internal tests"?

[Saadnajmi]

non blocking comment, how do we feel about having the webdriverio tests in FURN at all? I think the main usefulness from those tests may have now moved to our internal tests, and in FURN it feels like we've spent more time keeping them alive than not.
Some more context: one day I'd love to move Fluent Tester to use React Native Storybook, which would then use it's own testing suite and/or not use Appium. Have lots of ideas like this I'll probably never do though :)

Mind expanding a bit on this? "I think the main usefulness from those tests may have now moved to our internal tests"?

AFAIK, we're running Appium / webdriverio tests internally, and getting lots of value testing our features. However, the same E2E test suite in FURN has been disabled for android and iOS (not sure of Mac?) due to flakiness. React Native Core also switched away from Appium to Maestro due to flakiness in the open source repo. Given that most of the team is also working product side and not in this repo, I feel like the test suite has been more difficult to maintain which is part of why half the platforms ended up getting disabled instead of fixed - it's the fast unblock that we haven't prioritized to go back and fix. Well, at least not till Jason just did :). And as always, I might be biased, feel free to disagree with any of this

[samuelfreiberg]

non blocking comment, how do we feel about having the webdriverio tests in FURN at all? I think the main usefulness from those tests may have now moved to our internal tests, and in FURN it feels like we've spent more time keeping them alive than not.
Some more context: one day I'd love to move Fluent Tester to use React Native Storybook, which would then use it's own testing suite and/or not use Appium. Have lots of ideas like this I'll probably never do though :)

Mind expanding a bit on this? "I think the main usefulness from those tests may have now moved to our internal tests"?

AFAIK, we're running Appium / webdriverio tests internally, and getting lots of value testing our features. However, the same E2E test suite in FURN has been disabled for android and iOS (not sure of Mac?) due to flakiness. React Native Core also switched away from Appium to Maestro due to flakiness in the open source repo. Given that most of the team is also working product side and not in this repo, I feel like the test suite has been more difficult to maintain which is part of why half the platforms ended up getting disabled instead of fixed - it's the fast unblock that we haven't prioritized to go back and fix. Well, at least not till Jason just did :). And as always, I might be biased, feel free to disagree with any of this

I think that's fair - I'm not too familiar with how much this repo gets iterated on. I'm also surprised to hear that the E2E testing has been difficult to maintain. Is there any specific issues that have come up? Is it when we try to update Webdriverio or appium dependencies?

[Saadnajmi]

non blocking comment, how do we feel about having the webdriverio tests in FURN at all? I think the main usefulness from those tests may have now moved to our internal tests, and in FURN it feels like we've spent more time keeping them alive than not.
Some more context: one day I'd love to move Fluent Tester to use React Native Storybook, which would then use it's own testing suite and/or not use Appium. Have lots of ideas like this I'll probably never do though :)

Mind expanding a bit on this? "I think the main usefulness from those tests may have now moved to our internal tests"?

AFAIK, we're running Appium / webdriverio tests internally, and getting lots of value testing our features. However, the same E2E test suite in FURN has been disabled for android and iOS (not sure of Mac?) due to flakiness. React Native Core also switched away from Appium to Maestro due to flakiness in the open source repo. Given that most of the team is also working product side and not in this repo, I feel like the test suite has been more difficult to maintain which is part of why half the platforms ended up getting disabled instead of fixed - it's the fast unblock that we haven't prioritized to go back and fix. Well, at least not till Jason just did :). And as always, I might be biased, feel free to disagree with any of this

I think that's fair - I'm not too familiar with how much this repo gets iterated on. I'm also surprised to hear that the E2E testing has been difficult to maintain. Is there any specific issues that have come up? Is it when we try to update Webdriverio or appium dependencies?

At least from my perspective, it's usually something like "Wait why is CI failing? Nothing changed. Wait why are the Android E2E test failing? Is anyone using this on Android? Do I fix this or disable it to unblock <RN upgrade / bugfix / publish pipeline / etc>? And then never having time / priority to go back and fix it."
For a specific issue, I think I've found it hard to reproduce locally issues that CI sees, and it's usually not the test itself but getting a simulator / emulator set up properly and launched with the background with the bundle loaded, etc... When I had the thought process above (which was years ago I think), I think the issues is mostly setting up a new android/windows dev environment enough to run them in the first place. Once they run, I can't remember issues.