Move some of private commerce code packages to milo

[npeltier]

We are evaluating move to milo codebase of sources of dependencies:

1. https://git.corp.adobe.com/wcms/tacocat.js/tree/develop/packages/commerce that produces https://github.com/adobecom/milo/blob/stage/libs/deps/commerce.js and is only meant for enabling commerce capabilities on milo,
2. https://git.corp.adobe.com/wcms/tacocat.js/tree/develop/packages/web-components that produces /libs/deps/merch-*.js
   (all other tacocat packages would stay where they are atm)

we would keep build steps to keep decoupling of blocks & web components as well as being able to massage dependency files, but a change to one of those would be:
a. change of web component / commerce,
b. change of dependency,
c. change of consuming block,
(today on milo PRs, you only see b & c)

of course this is bringing a bit more complexity to milo repository, but we think it does belong there.
Please give your 2 cents, also where do you think we should put it.

[yesil]

I see those as two new projects under /libs/features (commerce, merch-web-components) that should not affect anyone but Warriors team.
At the first phase, I would not change the deps approach, where similar to SWC feature, the commerce developer makes the updates in the feature folder, generates the deps, and update the block codes consuming them.
The advantage is that everything could be fit in a single PR.

[mokimo]

Cool, great idea to find a new home for the code & bringing it closer to where it is consumed. I'm a little scared about the number of PRs that will roll in, given we already have a high daily PR count in milo core. BUT given that you need to to raise a PR to bump the dependencies, it's probably fine.

An idea I always instantly think of, is using the federal repo so that you have a different merge-pipeline and less clutter. That might not even be wanted as you get free sign offs with the stage initiative.

So ultimately, I'd think as Ilyas mentioned having an entry under /libs/features within milo itself would make sense.

[npeltier]

Cool, great idea to find a new home for the code & bringing it closer to where it is consumed. I'm a little scared about the number of PRs that will roll in, given we already have a high daily PR count in milo core. BUT given that you need to to raise a PR to bump the dependencies, it's probably fine.

i can guarantee you you'll not have more PRs, just the same number :) (but slightly bigger PRs :) )

[Axelcureno]

Will there be any sort of support for all this code in tacocat.js repo assuming we make this move? I remember hearing about doing 'maintenance support', what does that look like? What would be the plan if say if we need to consume these features in other surfaces like AH/CCD for example?

[npeltier]

🙂 you are right to mention that use case that was the first reason why we were decoupling repos. The first trials we are going to make though for those other surfaces are through milo which match with that initiative.
If people want to go through hard core integration (just picking up WC, and do whatever they want which i'm not sure we want to support), we could imagine them downloading them as they could do today.

[npeltier]

tracking the task in there https://jira.corp.adobe.com/browse/MWPW-151480

[yesil]

@npeltier currently we don't release packages to artifactory, but if we have to, this might be a bit challenging from the Milo repository.
Any thoughts on that?

[mokimo]

Why would you want to release anything to artifactory? If you are open source anyway, you can also just release to npm directly - unless you want to build the packages in a different way, but even then you could just have other consumers consume the code by drawing it in via www.adobe.com/libs/script-to-consume.js

[yesil]

Our future consumers for merch-card and potentially other web components, if they have a hard requirement to consume the library as an npm package as part of their build process, this can be an issue, even then, I agree we should push consumers to import the lib from adobe.com, because ultimately everyone should be running the same version of the cards.

[mokimo]

If they have a hard requirement to consume it as npm package, you can still just publish to npm rather than artifactory. In the dexter world we'd always consume NPM packages both from hosted npm instances and public ones.

You can also release NPM packages relatively simple using semantic-release as the franklin team does it:
https://github.com/adobe/helix-cli/blob/main/.github/workflows/main.yaml#L52-L70

[mokimo]

If it ever comes to it and you have the consumers that have hard requirements, I'd be glad to help setting this up if you move the repo to milo core.

[npeltier]

anything that is published in private artifactory should remain in private repository. What this discussion is about is commerce & WC that are public, and isolated enough to be there.
For consuming code let's talk more about it later :)

[npeltier]

one drawback i'm thinking of is github "updates" when PR is out of date. the fact we have source & built items in the same PR will make it impossible to merge the built items. Not sure we should make it a workflow, or just ban web updates.

[npeltier]

i also wonder @yesil @3ch023 what to do with things like merch-sidenav in the longer term. Wouldn't it be "better" to have sources moved to cc directly?

[3ch023]

Is there an issue keeping it in Milo? I understand that currently, we see no usage for it in the other consumers (this might change?), but I prefer all our components to be in one place.

[npeltier]

@mokimo as the only external contributor to that discussion, i inform you that we'll rather going to move code to github.com/adobecom/mas, we'll get back to you soon about this :)

[npeltier]

actually should we cc @mokimo @narcis-radu @3ch023 @yesil ?

@narcis-radu shew me ongoing work with bootstrapper for navigation, that is also serving centralized code (in milo) for several consumers (with non adobe.com ones).
current process with https://github.com/adobecom/mas (same as it was with private repo) is pretty cumbersome, but will change once we move dependency from there.
While it makes sense and look clean to have a separate codebase for some "outside" feature, i see immediate benefit of serving that central piece from its biggest (in terms of cards & features) consumer code base:

• consolidated PRs (service & consumption),
• already working validation process,
• already working code delivery process,

cons:

• tons of update to plan for non adobe.com cards, and PR # might not get much better (but with current temp situation it's not ideal neither)
• that weird build items + source libraries thing in same PR (e.g. some merch card source file + merch card bundle file + merch card block file change)

[rahulgupta999]

Can we create a wrapper to the aem code sync git app. That can first built the bundles and then probably invoke the aem code sync

[3ch023]

that weird build items + source libraries thing in same PR (e.g. some merch card source file + merch card bundle file + merch card block file change)

why is it a con? Since we have an automation already and /src changes will get built properly & auto-committed we'll have no risk of people forgetting the change of /deps. The only thing Milo is missing now - it allows to merge PRs not synced with the source branch ('stage'). We probably should request this rule change, if possible.

[3ch023]

Can we create a wrapper to the aem code sync git app. That can first built the bundles and then probably invoke the aem code sync

@rahulgupta999 could you give more details please?

[3ch023]

https://www.youtube.com/watch?v=hdcTmpvDO0I

:) it is time

[npeltier]

this change finally got done in #2606 closing this discussion.