Appium Monorepo Proposal

I propose to move Appiums core packages into a single repo to streamline the development of all non driver packages. I reviewed the packages in the Appium GitHub org and identified the following packages to be included:

• appium-remote-debugger
  • Dependencies:
    • appium-base-driver
    • appium-ios-device
    • appium-support
  • DevDependencies
    • appium-ios-simulator
• appium-support
• node-simctl
  • Dependencies:
    • appium-support
    • appium-xcode
• appium-xcode
  • Dependencies:
    • appium-support
• appium-adb
  • Dependencies:
    • appium-support
  • DevDependencies
• appium-ios-simulator
  • Dependencies:
    • appium-support
    • appium-xcode
• appium-base-driver
  • Dependencies:
    • appium-support
• appium-doctor
  • Dependencies:
    • appium-support
    • appium-adb
• appium-idb
  • Dependencies:
    • appium-support
• appium-ios-device
  • Dependencies:
    • appium-support
• eslint-config-appium

Setup

The setup of the mono repo should be aligned to Lernas best practices. To avoid unnecessary complexity I recommend to not include Appiums gulp plugins and rather use NPM scripts. For example to watch all packages and compile them on file change we could use a custom script that watches all packages at the same time.

I also recommend to switch from the current test stack (Mocha / sinon) to Jest. It comes with an assertion and mocking library built in and can remove a lot dependencies and helper packages such as appium-test-support. It also simplifies tracking the coverage across the whole repository.

Package Naming Convention

The ability to pin versions of inter dependencies turns out to be very valuable when developing in a mono repo setup. Therefor I recommend to move all packages into an @appium namespace, e.g.:

• appium-remote-debugger -> @appium/remote-debugger
• node-simctl -> @appium/node-simctl

This allows us to start at v2.0 across all packages and pin them to each other. At the same time it simplifies the transition to Appium 2.0.

Testing Strategies

I am not much familiar with what is being tested in the packages mentioned above but ideally they should not need a different environment other than Node.js. For example the appium-adb package should not need ADB to test its functionality. It is up to the driver to ensure that their commands work on the actual environment they are suppose to control. Given that there will be a lot of tests to be run they need to run fast and should not require any special dependencies to keep it simple to execute for collaborators.

Transition

Transitioning from the current setup to the desired will be the most challenging part. The advantages of streamlining the development need to be evaluated and compared if it is worth cost of transitioning. I propose that all contributions to the packages mentioned above need to be proposed with 2 separated PRs. One to the original source (e.g. this master branch or subpackage repo master) and one to the new setup source (e.g. this v2.0 branch).

This might ultimately make contributions a bit more difficult given that 2 PRs need to be proposed but it guarantees that the functionality between the packages stays the same. Given the type of patch that is proposed, porting the functionality can be done by the Appium core team and deferred to a later point in time.

[boneskull]

FWIW, I will be able to assist in ensuring Mocha meets the needs of Appium. From what I can tell, switching to Jest is often more work than expected.

[jlipps]

I think I agree with @mykola-mokhnach and @KazuCocoa that platform-specific ios or android stuff should maybe be isolated to separate monorepos focused on those platforms, or even brought entirely under driver packages. so for example, we only support one ios driver at the moment, so there’s not a lot of reason for separate repos for all the ios related stuff. it could all be in a monorepo along with the xcuitest driver.

likewise for android, though we support two android drivers moving forward (uia2 and espresso). but still, they could both be part of one monorepo. in the case of uia2 and espresso, there is so much shared code and logic that it makes sense to have them be in the same repo, since the same people would plausibly work on both.

what do you think about this @christian-bromann?

as far as possible, each driver should just be one repo with the main driver along with any supporting packages.