Problem
The aem content commands are pinned to one da.live backend. src/content/da-api.js hardcodes DA_ADMIN = 'https://admin.da.live', and src/content/da-auth.js hardcodes the IMS origin, client id, and scope. Pointing the content commands at a different da.live admin backend or IMS provider means editing the source, which blocks testing against a non-default backend and any multi-environment workflow.
Proposal
Resolve the da.live admin host and IMS provider from environment variables, defaulting to today's production values. With nothing set, the commands talk to admin.da.live exactly as they do now.
AEM_DA_ADMIN - da.live admin host (default https://admin.da.live)AEM_DA_IMS_ORIGIN - IMS origin (default https://ims-na1.adobelogin.com)AEM_DA_IMS_CLIENT_ID - IMS client id (default unchanged)AEM_DA_IMS_SCOPE - IMS scope (default unchanged)
yargs already reads AEM_-prefixed variables (.env('AEM_') in src/cli.js). Load a local .env through dotenv (already a dependency) at the top of src/cli.js, before yargs parses; a real shell variable wins over the file. Add .env to .gitignore.
A token minted against one backend must not be reused against another, so cache the token per backend by keying the token file on the resolved admin host. admin.da.live keeps its current .hlx/.da-token.json, so nothing migrates for existing users.
These are advanced options and stay out of --help.
Cross-backend copy
Once the backend is configurable, aem content can copy content between two da.live backends: clone from one, point the environment at the other, push. A push to a different backend than the clone source cannot trust the baseline recorded at clone time, so it skips the baseline conflict check and requires --force, running as a copy rather than a sync.
Scope
Content commands and their shared auth only. No change to org/site addressing. Production stays the default.
Problem
The
aem contentcommands are pinned to one da.live backend.src/content/da-api.jshardcodesDA_ADMIN = 'https://admin.da.live', andsrc/content/da-auth.jshardcodes the IMS origin, client id, and scope. Pointing the content commands at a different da.live admin backend or IMS provider means editing the source, which blocks testing against a non-default backend and any multi-environment workflow.Proposal
Resolve the da.live admin host and IMS provider from environment variables, defaulting to today's production values. With nothing set, the commands talk to
admin.da.liveexactly as they do now.AEM_DA_ADMIN- da.live admin host (defaulthttps://admin.da.live)AEM_DA_IMS_ORIGIN- IMS origin (defaulthttps://ims-na1.adobelogin.com)AEM_DA_IMS_CLIENT_ID- IMS client id (default unchanged)AEM_DA_IMS_SCOPE- IMS scope (default unchanged)yargs already reads
AEM_-prefixed variables (.env('AEM_')insrc/cli.js). Load a local.envthroughdotenv(already a dependency) at the top ofsrc/cli.js, before yargs parses; a real shell variable wins over the file. Add.envto.gitignore.A token minted against one backend must not be reused against another, so cache the token per backend by keying the token file on the resolved admin host.
admin.da.livekeeps its current.hlx/.da-token.json, so nothing migrates for existing users.These are advanced options and stay out of
--help.Cross-backend copy
Once the backend is configurable,
aem contentcan copy content between two da.live backends:clonefrom one, point the environment at the other,push. Apushto a different backend than theclonesource cannot trust the baseline recorded at clone time, so it skips the baseline conflict check and requires--force, running as a copy rather than a sync.Scope
Content commands and their shared auth only. No change to
org/siteaddressing. Production stays the default.