CEXT-5327: Integrate adobe/aio-commerce-lib-config

[iivvaannxx]

Description

Integrates the new business configuration library as an initial step towards unified app-management. Renames environment variables as needed per the generated actions.

Additional Fixes

• Fix the Node Version in the ci.yml, which was mismatched from the required version declared in the package.json engines property.

Ticket

CEXT-5327

[obarcelonap]

Some doubts from my side

[obarcelonap]

can you elaborate on the general concept about this and how it is used in config management?
first time I see

[iivvaannxx]

Not particularly aware of what's the use case but is something that @asalloum5 spoke in the past and he might be able to explain it.

[obarcelonap]

found this looking in the docs but not sure about its effect https://developer.adobe.com/app-builder/docs/guides/app_builder_guides/configuration/configuration#definition-of-dxasset-computeworker1

[iivvaannxx]

IIRC, it allows to get a list of the operations an extension point has (some kind of metadata). This serves the purpose of not having to guess (or assume) that some operation is present, and also know which is the runtime action that performs it.

[obarcelonap]

action is not hitting the instance, are you sure injecting the credentials is required?

[iivvaannxx]

I believe for this runtime action hitting commerce is "optional" on whether you feed the commerceConfig or not, but I didn't implement so not sure why. @aminakhyat Implemented that and she's out these days, but maybe @emartinpalomas knows the answer 🤔

[obarcelonap]

same comment about least privilege principle, we have to be careful on injecting the minimum credentials as possible

[obarcelonap]

would be nice to be able to configure this using an env var

[iivvaannxx]

Will create a patch in @adobe/aio-commerce-lib-config to fix that 👍🏻

[obarcelonap]

is this file autogenerated? if so it is missing the notice

[iivvaannxx]

Good point, will add

[obarcelonap]

probably has to be moved into .generated folder too

[iivvaannxx]

Yes and no, while some of it's contents are auto-generated, you might want to add some extra configuration to it. You may want to add a hook for example, in the current implementation I placed hooks in the app.config.yaml, but nothing stops you from doing it in the ext.config.yaml.

Having it in .generated would be confusing in that sense. But will keep it in mind and discuss it with @aminakhyat when she comes back. For now, I'll add only a comment to the generated properties.

[obarcelonap]

is this two dashes syntax correct?

[iivvaannxx]

Yep, include is actually an array of arrays in the shape of [[source, dest], [source, dest]]. I'd prefer to write this in the format of multiple - [source, dest] but that is the output of the yaml stringify operation.

[obarcelonap]

Not sure if you need this IMS credentials here: if the requestor is from Commerce admin or Unified Shell the token should have already the needed scopes to request to the instance. Therefore, you can just grab the token from Authentication header and forward.
Same for PaaS if they use IMS, not sure if we need integration creds.
Have you explored this option?

[iivvaannxx]

Probably not, token forwarding is something that we can implement but it's not present right now, so as of this moment we need the inputs.

[obarcelonap]

I believe is important in this case since code is autogenerated from a lib we provide, should follow least principle privilege. I'd strongly suggest you consider token forwarding for the config implementation (extra points if it comes from the auth lib).