IMPROVE ALL THE REPOS – exploring Microsoft’s DevExp

Microsoft is big. Like, REALLY BIG. This means 100s of engineers working in their huge monorepos, and React Native experiences being thrown around across them... how can this even work? How do you improve, coordinate, remove frictions for so many codebases?
In this talk, we will dive a bit deeper on the technical side to present you some of the unique challenges we face at the MS scale, and introduce you to some of our custom tooling – who knows, maybe it will be helpful for you too?

Transcript

1. An exploration of
   RN’s MS’ DX
   React Native Europe 2021
   

   View Slide

2. The Microsoft
   galaxy
   • Microsoft has many monorepos
   • A monorepo is a place in which
   many different packages
   coexist, aware of each other
   Photo by Graham Holtshausen on Unsplash
   2
   

   View Slide

3. To navigate
   this cosmos,
   here are your
   astronauts
   Tommy Nguyen
   @tido64 (GitHub)
   Principal Software Engineer
   Photo by Graham Holtshausen on Unsplash
   Lorenzo Sciandra
   @kelset
   Senior Software Engineer
   React Native Maintainer
   3
   

   View Slide

4. React Native at MS
   Covering a few basics
   4
   

   View Slide

5. How did React
   Native at
   Microsoft
   start?
   – Original exploration happened in Skype
   – After a first greenfield attempt, the next step was understanding
   how to integrate within existing apps
   – The brownfield approach organically propagated within different
   organizations in Microsoft
   5
   

   View Slide

6. The concept
   of experiences
   – In Microsoft, as in other big corps, we use React Native to create
   features to include in existing apps
   – The idea is to abstract away the complexities of handling with
   React Native as a tool: the developers only need to worry about
   writing JS
   experience
   hostapp
   A
   B
   6
   

   View Slide

7. The challenges
   Who keeps
   RN updated
   in each
   codebase?
   When do you
   bump RN? What if our
   configurations
   are different?
   What if my
   experience targets
   multiple products?
   How do we use OSS
   libraries?
   Photo by Graham Holtshausen on Unsplash
   7
   

   View Slide

8. Diving deep
   Let’s focus on 2 of those challenges
   8
   

   View Slide

9. The 2 main
   challenges
   #1:
   how can we separate the developer experience from the complexity
   of the tooling?
   #2:
   how can we reduce the burden of alignment across different
   monorepos?
   9
   

   View Slide

10. Problem #1:
    separate the developer
    from the toolchain experience
    hostapp
    A
    B
    10
    

    View Slide

11. Solution:
    React Native Test App
    – REACT NATIVE TEST APP is a super compact RN app that hides
    the complexity of a greenfield app below the surface.
    – Similarly to Expo’s client, the developer only needs to worry about
    the JavaScript code for their experience – but you still have full
    control of the native code.
    – It supports many different RN versions, via a simple configuration
    change.
    11
    

    View Slide

12. “Demos speak louder
    than words”
    -Sun Tzu, or something
    Showing off RNTA
    12
    Find the full demo at https://github.com/tido64/rneu-demo
    

    View Slide

13. View Slide

14. RNTA
    how we use it BENEFITS
    – Fewer engineers need to worry about the inner works of RN (or iOS
    or Android or macOS or Windows), they can just use it
    – Easier to upgrade than a standard RN project
    – If there’s a custom fix or workaround that you need, you can
    implement it once and use it across the entire monorepo… or even
    the entire company
    Experience 1
    A
    Experience 2
    14
    

    View Slide

15. Problem #2:
    align the monorepos
    RN v.X
    Package A: v1
    Package B: v2
    Hermes: NO
    RN v.Y
    Package A: v1
    Package B: v3
    Hermes: YES
    RN v.Z
    Package A: v3
    Package C: v3
    Hermes: YES
    RN v.X
    Package C: v1
    Package B: v1
    Hermes: NO
    15
    

    View Slide

16. Solution:
    @rnx-kit/dep-check
    – DEP-CHECK is a tool that can understand the dependencies in a
    package.json and can modify it, based on a series of curated
    profiles.
    – It can even fix misconfigured package.json – the developer simply
    defines a local dep-check configuration, and the tool will take care
    of declaring the right packages, at the right version, in the right
    section.
    16
    

    View Slide

17. “A demo is stronger
    than a big bang”
    -Einstein, probably
    Showing off RNX-KIT dep-check
    17
    Find the full demo at https://github.com/tido64/rneu-demo
    

    View Slide

18. View Slide

19. dep-check
    how we use it
    BENEFITS
    – List of dependencies and versions is curated: teams can just trust it
    – Can be run on CI to ensure that no divergences happen
    – You can introduce custom profiles.. And even export them among
    different monorepos!
    *
    19
    

    View Slide

20. To recap
    – REACT NATIVE TEST APP
    to separate the developer experience from the complexity of the
    tooling
    – @RNX-KIT/DEP-CHECK
    to reduce the burden of alignment across different monorepos by
    relying on automation
    20
    

    View Slide

21. Concluding
    – These solutions are the byproduct of “lessons we learned the hard
    way”, and we are pretty sure most of you are facing some similar
    challenges
    – ...so what if our tools were OSS and you could use them?
    21
    

    View Slide

22. Introducing
    https://github.com/microsoft/react-native-test-app https://github.com/microsoft/rnx-kit
    22
    

    View Slide

23. Thank you
    for listening!
    Lorenzo Sciandra
    @kelset
    Senior Software Engineer
    React Native Maintainer
    Tommy Nguyen
    @tido64 (GitHub)
    Principal Software Engineer
    https://github.com/microsoft/rnx-kit
    https://github.com/microsoft/react-native-test-app
    23
    React Native Europe 2021
    

    View Slide