# Code sharing user scenarios

## User descriptions

I am a OneDrive dev, building the Files experience to be hosted in OneDrive, Teams, and Outlook.

I am an Outlook dev, building the Calendar experience to be hosted in Teams, SharePoint, and Outlook.

I am a Ribbon dev, building the Ribbon to be hosted in multiple Office apps, and possibly 3rd party apps.

I am a Fluent UI dev, building component building blocks to be consumed in all of the above including 3rd party apps.

## Cases these shared code devs go through

### I want to build and integrate a shared library across repo boundaries

Inner loop scenarios:

1. I want to start a new shared library project
a. I need a project template
b. I need to know what and what not to do (shared libraries need to have a very explicit contract, tests to cover those contracts, docs)
b. I need a repo
c. I need a CI
d. I need it to auto publish
e. I need it to be discoverable (npm package, public or private)
2. I want to integrate a shared library into an app
a. I need to clone the library and the app repos
b. I need to link them together
c. I need to localhost app
3. I want to make local changes to 1 or more shared libraries, and see them integrated into a live app without deploying it
4. When I submit a PR to my library, I want to provide devs with a durable url to test the changes in an endpoint.

### I want my shared library to be trustworthy

When bugs in my library make it to the app, it hurts trust in sharing code.

Testing scenarios to prevent bugs:

5. I want to have my CI run multiple endpoint consumer tests with my local library to prevent bugs downstream.
6. I want endpoints to have visual regression tests informing me when i change their app pixels unintentionally.
7. When a bug is found I want to go to the exact configuration of the app that it was found in, with debug source maps so that I can pinpoint the bug and plan a fix.
8. An endpoint can be easily re-tested without building because their tests can run as an npm package the tests against the live site or service. (tests as a package.)

### I want my library to always be up-to-date in endpoints

7. I want my library changes to be automatically picked up by applications
8. When a problem occurs with an automated update, I want to know about the problems a partner had with my changes so that we can unblock.
9. My change requires library changes AND app changes, living in separate repos. I want to make all the changes and then have them consumed in the right order with minimal effort.
10. A tree of dependencies exist - ui library -> experience -> app code, and they all require updates. Coordinate all of them.