Moving MAS Feature from Milo to MAS Repository

[yesil]

Background

Last year, the Warriors team was tasked with working on multiple Milo commerce blocks (mainly merch-card related), which required code synchronization with MAS commerce web components.

To streamline development, we decided in August 2024 to move MAS commerce web components into the Milo repository allowing us to deliver fixes and features in a single PR.

However, the landscape has changed:

• MAS Studio has gone live (currently with limited features).
• Features like merch-cards, catalog, plans, and other related apps will increasingly be authored within MAS Studio.

As a result, we now face a similar need—to deliver all these features within the MAS repository using a single PR.

---

Impact on Milo

Currently, Milo relies on the following MAS commerce features:

• commerce.js → Provides core pricing and checkout link/button capabilities.
• merch-card.js → provides all merch card variants
• merch-card-collection.js → Manages card collections (e.g., catalog and upcoming plans pages).

With this move, we considered two possible approaches:

Option 1: Go Evergreen

Milo will dynamically load the above dependencies from: www.(stage).adobe.com/mas/*

This ensures Milo always uses the latest version of MAS components.

Option 2: Cumulative PRs

If the option 1 doesn't work out, we will combine multiple fixes generate the above dependencies and make a single Milo PR.

Please let me know your thoughts and if you see other options.

[chrischrischris]

Option 1 - Painful upfront to deal with getting it all setup, but then never have to worry about it vs continuing pain

[Axelcureno]

I also vote for option 1.

[npeltier]

It feels to me we should also talk about rationale behind 1/2 of moving things away from milo, and thus still leave us an option 3: leaving things as they are.

What's hitting us right now is that most of the changes you mentionned result in 2 PRs for us (1 on mas, 1 on milo), and impact our velocity quite high. Plus related oddities we are trying to work around https://github.com/orgs/adobecom/discussions/3443. We need though with Option 1 to leverage the quality insurance we have right now and bring commerce related milo nala tests to mas PR process.

[3ch023]

Option 1

I think we have good changes to go evergreen, because I can't remember ever reverting our commerce PR from stage because of late-found bug. It means we could rely on our own efforts verifying PRs in mas repo without a need of SOTs approve.
However I do believe we will need:

• ability to keep running Milo Nala tests on each of our mas PRs (for PRs touching Milo dependency)
• 100% strict process on how we act if CSO issue is found post-merge of mas PR
• follow RCP. in the beginning - no merges of fridays/late CET eve.
• in specific cases, we might still want to request SOTs check on pending PR that we think is risky

Question is, how can we run Milo Nala tests from mas repo?
Do we have a github action that will checkout milo repo, and run them on something like 'mwpw-166677--mas--adobecom'?

Alternatively, we don't run Milo Nala tests and just run 'our' merch ones. But it sounds too risky?

Option 2

It could work as well, but I think we should choose an automation oriented way - option 1.
Benefit - we can merge during RCP that will be faster

Option 3

Similar as option 2, we could continue with two PRs for the time being and try to adjust milo automation to deal with our PRs better.
Details in https://github.com/orgs/adobecom/discussions/3443
I stopped liking this option because:

• it might be the same effort as Option 1.
• In some moments we would want to merge 3-4 PRs a day, and it's unlikely that it would happen with Milo

[honstar]

+1 for option 1.

Given the wider deployment of m@s, especially with the growing adoption of M@S studio across surfaces, it makes more sense imo to make m@s a dependency for milo rather than an integral part of it.