feat(lightning-out): add `template generate lightning-out` command @W-24035498@ by akashdhake · Pull Request #1048 · salesforcecli/plugin-templates

akashdhake · 2026-09-07T16:59:20Z

What

Adds the sf template generate lightning-out command (beta, hidden) — a generate-only scaffolder for Lightning Out 2.0 setup. Writes the 7 LO2 metadata artifacts (via the companion @salesforce/templates generator, PR forcedotcom/salesforcedx-templates#880); deploys nothing itself and never contacts an org.

Command layer

Flags: --app-name, --eca-name, --runtime (LWR_CORE|CLWR), --host-domains (multiple), --components (multiple), --eca-contact-email, --eca-callback-url, --definition-file, --output-dir, --api-version.
Input resolution: merges --definition-file + flags into one options object with per-key precedence; list keys (host-domains, components) replace wholesale.
Advisories: emits a CLI-side sourceApiVersion < 68 deploy-floor warning and flags unknown --definition-file keys; prints post-generate deploy guidance.
No iframe / force / prompt / distribution-state / oauth-scopes machinery (invariants are hardcoded in the generator).

Testing

Unit tests: merge precedence, list-replace semantics, definition-file fallback, unknown-key reporting, beta/hidden.
NUT: drives the command end-to-end, asserts exactly the 7 artifact types land (correct folders/filenames/contents) and that iframeWhiteListUrlSettings is absent; validation failure exits non-zero cleanly.
Verified against a live local-Core org (generate → deploy 10/10 succeeded).

Work item: W-24035498 (@W-24035498@)

Reads a JSON definition file and scaffolds the LO 2.0 metadata via @salesforce/templates. Always warns that the generated IframeWhiteListUrlSettings REPLACES the org's Trusted Domains list on deploy. Generate-only.

…conciliation

… success output - Rewrite src/commands/template/generate/lightning-out/index.ts to match the shipped @salesforce/templates LightningOutOptions shape (appName/eca.name, no distributionState/oauthScopes/force). Drops the interactive iframe-confirm/cancel path, --force, --no-prompt, --eca-distribution-state, --eca-oauth-scopes, and the old flat --name flag; adds --app-name, --eca-name. Extracts a pure, exported mergeLightningOutInputs() for per-key flag/definition-file precedence with wholesale list-replace for hostDomains/components, and a getSourceApiVersion() helper (SfProject, best-effort) for a CLI-side sourceApiVersion<68 advisory. Surfaces the generator's result.warnings and prints success guidance via this.info. - Rewrite messages/lightningOut.md to the exact key set run() references (verified by grep): drops iframe/force/no-prompt/eca-distribution-state/ eca-oauth-scopes/flags.name/error.missing-inputs keys, adds app-name/eca-name/definition-file summaries, error.definition-file-not-object, warning.unknown-definition-key, warning.source-api-version, and the success.* guidance keys. - Add unit test test/commands/template/generate/lightning-out/index.test.ts covering mergeLightningOutInputs precedence, list-replace semantics, and unknown-key reporting, plus the beta/hidden command metadata. - Regenerate command-snapshot.json and schemas/*.json (oclif `snapshot generate` / `schema generate`) so test:deprecation-policy and test:json-schema stay green against the new flag set; the schema diff for commands other than lightning-out is solely the pre-existing CreateOutput.warnings field already shipped by the linked generator.

…r predicate

…s without warnings field

… flags cast

jshackell-sfdc

See my suggestions, comments, and questions.

jshackell-sfdc · 2026-09-21T16:15:40Z

+
+# description
+
+Generates the seven metadata artifact types a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it does not deploy and never contacts an org.


Suggested change

Generates the seven metadata artifact types a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it does not deploy and never contacts an org.

Lightning Out 2.0 is a Salesforce app that you use to embed custom Lightning web components (LWC) into your external, non-Salesforce apps.

This command gets you started by generating into your Salesforce DX project the seven metadata artifact types that a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it doesn't deploy any metadata to an org.

jshackell-sfdc · 2026-09-21T16:16:15Z

+
+# summary
+
+Generate the metadata scaffold for a Lightning Out 2.0 application.


Suggested change

Generate the metadata scaffold for a Lightning Out 2.0 application.

Generate the required metadata to scaffold a Lightning Out 2.0 app.

jshackell-sfdc · 2026-09-21T16:17:13Z

+
+# flags.app-name.summary
+
+Metadata API name of the Lightning Out 2.0 app.


Suggested change

Metadata API name of the Lightning Out 2.0 app.

Developer name of the new Lightning Out 2.0 app.

Okay? We tend to use "developer name" to specify the unique ID for MD components. Unless "metadata api name" is something different? If so, stick with "metadata api".

jshackell-sfdc · 2026-09-21T16:21:12Z

+
+# flags.eca-name.summary
+
+Metadata API name of the External Client Application (OAuth) associated with the app.


Suggested change

Metadata API name of the External Client Application (OAuth) associated with the app.

Developer name of the External Client Application (OAuth) associated with the app.

Same comment as above.

jshackell-sfdc · 2026-09-21T16:24:53Z

+
+# flags.runtime.summary
+
+Runtime the app targets: LWR_CORE or CLWR. CLWR is experimental.


I don't understand what this means, so I don't have a suggestion for a better summary. But for starters, it would be good to explain what LWR_CORE and CLWR mean. For example, something like:

"Runtime used to run the Lightning Out app. LWR_CORE is blah blah blah, CLWR is blah blah blah."

For maintenance reasons, I wouldn't mention that CLWR is experimental unless it's going to stay that way forever. Just my $.02.

Done — dropped "experimental" and expanded both runtimes as you suggested. It now reads:

Runtime the app targets. LWR_CORE serves from your Salesforce org for authenticated users; CLWR serves from an Experience Cloud site (guest access, extra site-deployment step).

jshackell-sfdc · 2026-09-21T16:32:15Z

@@ -0,0 +1,99 @@
+# examples
+
+- Generate from individual flags (discoverable via --help; the nested eca block is flattened into --eca-\* flags):


Suggested change

- Generate from individual flags (discoverable via --help; the nested eca block is flattened into --eca-\* flags):

- Generate a Lightning Out 2.0 app using individual flags to specify the values:

It's standard to find the flag names using --help, so no need to mention it. And I think the note about the eca block is also unnecessary.

jshackell-sfdc · 2026-09-21T16:36:51Z

+
+  <%= config.bin %> <%= command.id %> --app-name MyLoApp --runtime LWR_CORE --host-domains https://example.com --eca-name MyLoAppEca --eca-contact-email dev@example.com --eca-callback-url https://example.com/cb
+
+- Generate from a JSON definition file (like "sf org create scratch --definition-file", the whole input set — including the nested eca block — lives in one file):


Suggested change

- Generate from a JSON definition file (like "sf org create scratch --definition-file", the whole input set — including the nested eca block — lives in one file):

- Generate an app using the values in a JSON definition file called lo-def.json:

jshackell-sfdc · 2026-09-21T16:37:22Z

+
+  <%= config.bin %> <%= command.id %> --definition-file lo-def.json
+
+- Generate into a specific directory:


Suggested change

- Generate into a specific directory:

- Generate the app into a specific directory:

jshackell-sfdc · 2026-09-21T16:39:40Z

+
+  <%= config.bin %> <%= command.id %> --definition-file lo-def.json --output-dir force-app/main/default
+
+- Mix a definition file with an override flag (flags win over the file, per key):


Suggested change

- Mix a definition file with an override flag (flags win over the file, per key):

- Generate the app using most of the values from a definition file, but the --host-domains value overrides its equivalent in the file:

jshackell-sfdc · 2026-09-21T16:40:34Z

+
+Generates the seven metadata artifact types a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it does not deploy and never contacts an org.
+
+Inputs may come from a --definition-file JSON, individual flags, or both — flags take precedence over the file on a per-key basis. All structural validation (required fields, formats) is performed by the underlying generator.


Suggested change

Inputs may come from a --definition-file JSON, individual flags, or both — flags take precedence over the file on a per-key basis. All structural validation (required fields, formats) is performed by the underlying generator.

Inputs may come from a --definition-file JSON, individual flags, or both. Flag values take precedence over the file on a per-key basis. All structural validation (required fields, formats) is performed by the underlying generator.

srijanakde2001

Review focused on the executable TypeScript and tests; documentation changes were intentionally omitted.

srijanakde2001 · 2026-09-22T07:38:07Z

+      const dir = outDir('bad-host-domain');
+      const stderr = execCmd(
+        'template generate lightning-out --app-name BadHostApp --eca-name BadHostApp_ECA --runtime LWR_CORE ' +
+          `--host-domains http://app.example.com --components c/myButton --eca-contact-email dev@example.com --eca-callback-url https://app.example.com/cb --output-dir ${dir}`,


@salesforce/templates v66.16.0 deliberately accepts both HTTP and HTTPS host origins, so this input succeeds and exits 0. As written, ensureExitCode: 1 should make this NUT fail against the released generator. Could we use a genuinely invalid origin such as ftp://app.example.com and assert that the error mentions http or https? If the CLI is intended to require HTTPS, it needs explicit command-layer validation instead.

Good catch — done. The NUT now uses ftp://app.example.com and asserts the error names the scheme (matches /host domain/i + /http or https/i), since http/https are both valid inputs to the v66.16.0 generator. We're keeping the "recommend, don't enforce" stance (no command-layer HTTPS requirement), which matches the generator's design — it only rejects non-http(s) schemes.

srijanakde2001 · 2026-09-22T07:38:07Z

+
+    it('should scaffold exactly the seven artifact types', () => {
+      const projectOutDir = path.join(session.project.dir, 'force-app', 'main', 'default');
+      assert.file([


Could we assert representative generated XML contents here, in addition to filenames? For example, verify the runtime, component, and normalized host domain in LightningOutApp, plus the callback URL or contact email in the ECA metadata. The current test would still pass if the command stopped forwarding or misrouted one of those values, as long as files with the expected names were created.

Added. A new it('should render the input values into the generated metadata ...') now reads the generated XML and asserts: <runtime>, <componentName>, and both <hostDomain> values in LightningOutApp; contactEmail in the .eca artifact; and the callback URL in the .ecaGlblOauth artifact. So a stopped or misrouted value now fails the test even when files with the right names exist.

srijanakde2001 · 2026-09-22T07:38:07Z

+  const unknownKeys = Object.keys(defn).filter((k) => !known.has(k));
+  const ecaDefn = (defn.eca ?? {}) as Record<string, unknown>;
+  const opts: LightningOutOptions = {
+    appName: flags['app-name'] ?? (defn.appName as string),


These casts allow valid JSON with incorrect value types to bypass this layer. For example, "appName": 123 or "eca": {"contactEmail": 123} reaches the generator, which calls .trim() and throws an internal TypeError such as trim is not a function, rather than an actionable definition-validation error. Could we validate the definition-file shape before constructing LightningOutOptions, or update the generator to handle unknown values safely?

Fixed. Added validateDefinitionShape(defn, flags) which type-checks the definition-file fields before building LightningOutOptions (new error.definition-file-field-type message: Definition file field "%s" must be %s.). {"appName": 123} or {"eca": {"contactEmail": 123}} now produces an actionable definition-validation error instead of an internal TypeError. Validation is skipped per-key when a flag overrides that field, since flags always arrive as strings and win per-key.

srijanakde2001 · 2026-09-22T07:38:07Z

+    }
+
+    // Success guidance (suppressed automatically under --json).
+    this.log(messages.getMessage('success.next-step', [opts.outputdir ?? '.', opts.outputdir ?? '.']));


Could we shell-quote the output directory in the suggested deploy command? If the command is run with --output-dir "/tmp/Lightning Out", this currently prints sf project deploy start -d /tmp/Lightning Out ...; copying it causes the shell to treat Out as a separate argument. This does not affect generation itself, but it makes the advertised next step fail for valid paths containing spaces.

Done. Added shellQuoteArg(), and success.next-step now single-quotes the output dir when it contains whitespace or quote chars — --output-dir "/tmp/Lightning Out" now prints a copy-pasteable ... --source-dir '/tmp/Lightning Out' .... (Also switched the suggested command from -d to --source-dir.)

srijanakde2001 · 2026-09-22T07:38:07Z

+      callbackUrl: flags['eca-callback-url'] ?? (ecaDefn.callbackUrl as string),
+    },
+    outputdir: flags['output-dir'],
+    apiversion: flags['api-version'],


What behavior is --api-version intended to control here? The v66.16.0 Lightning Out generator accepts apiversion, but the generated templates do not use it, while the floor warning below checks only sfdx-project.json. Consequently, a v70 project with --api-version 67.0 receives no warning, and a v67 project with --api-version 70.0 still receives one. Could we either validate the effective version as flags["api-version"] ?? sourceApiVersion, or remove the flag if it is not intended to affect this command?

Removed the flag. Investigating confirmed it's inert for this command: none of the seven LO scaffold artifacts carry an <apiVersion> element, and the v66.16.0 generator never reads apiversion — so it couldn't affect output, which is exactly the inconsistency you flagged. Dropped --api-version from the command and from command-snapshot.json. The deploy floor is handled separately (the hardcoded --api-version 68.0 in the suggested deploy command + the sourceApiVersion floor warning), so that guidance is unaffected.

Follow-up in c8a4317: refined the printed deploy command so it no longer hardcodes --api-version 68.0 on every run. Since 68.0 is the deploy floor (not a recommended version), pinning it would downgrade a project already on a higher version. Now the suggestion includes --api-version 68.0 only when the project's sourceApiVersion is actually below the floor (same condition that fires the floor warning); at/above floor it's omitted so the project default applies. Added a NUT covering both branches.

…tion, drop inert --api-version

akashdhake · 2026-09-22T11:56:52Z

@jshackell-sfdc Thanks for the thorough copy pass — applied all the wording suggestions in commit 5272b27 (examples, summary, description, and the flag summaries). Two intentional divergences from the literal suggestions, both explained inline on their threads:

--host-domains reads "HTTP or HTTPS" rather than "HTTPS" — the generator accepts both schemes and only rejects non-http(s) ones, so "HTTPS" would misdescribe the behavior.
The description's validation paragraph is reworded: the command now type-validates --definition-file fields (see the thread on Srijanak's review), while the generator still performs the remaining structural validation (required fields, formats).

subashbabu-pixel · 2026-09-22T12:33:30Z

+
+# summary
+
+Generate the required metadata to scaffold a Lightning Out 2.0 app.


Terminology — confirm product name. Use the approved external name "Lightning Out" ("2.0" is internal shorthand for the GA-vs-Beta distinction). Please confirm before merge. The same change applies to lines 3, 33, and 61 (lines 25 and 27 are already covered by the suggestions there).

Suggested change

Generate the required metadata to scaffold a Lightning Out 2.0 app.

Generate the required metadata to scaffold a Lightning Out app.

Discussed this naming with our PM (Sangeeta): we're keeping Lightning Out 2.0 until the beta version is completely sunset. Otherwise devs may take "Lightning Out" to be the beta, or be unsure whether it's the beta or the latest. Once beta is deprecated we'll drop the "2.0" and use the name as-is. Leaving it unchanged for now.

subashbabu-pixel · 2026-09-22T12:33:31Z

+
+# description
+
+Lightning Out 2.0 is a Salesforce app that you use to embed custom Lightning web components (LWC) into your external, non-Salesforce apps.


Accuracy + grammar. "is a Salesforce app" conflates the product with the LightningOutApp this command generates; "(LWC)" should be plural.

Suggested change

Lightning Out 2.0 is a Salesforce app that you use to embed custom Lightning web components (LWC) into your external, non-Salesforce apps.

Lightning Out lets you embed custom Lightning web components (LWCs) into your external, non-Salesforce apps.

Done — reworded to "Lightning Out 2.0 lets you embed custom Lightning web components (LWCs) into your external, non-Salesforce apps." (fixed the "is a Salesforce app" phrasing and (LWC) → (LWCs)). Kept the "2.0" per the naming note on the first thread.

subashbabu-pixel · 2026-09-22T12:33:33Z

+
+Lightning Out 2.0 is a Salesforce app that you use to embed custom Lightning web components (LWC) into your external, non-Salesforce apps.
+
+This command gets you started by generating into your Salesforce DX project the seven metadata artifact types that a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it doesn't deploy any metadata to an org.


Clarity. Move the target ("into your Salesforce DX project") to the end, and replace the informal "trio."

Suggested change

This command gets you started by generating into your Salesforce DX project the seven metadata artifact types that a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it doesn't deploy any metadata to an org.

This command gets you started by generating the seven metadata artifact types that a Lightning Out app requires into your Salesforce DX project: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the three External Client Application OAuth components (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it doesn't deploy any metadata to an org.

Done — moved "into your Salesforce DX project" to the end and replaced "OAuth trio" with "three External Client Application OAuth components". Kept "a Lightning Out 2.0 app requires" per the naming note.

subashbabu-pixel · 2026-09-22T12:33:35Z

+
+# flags.host-domains.summary
+
+HTTP or HTTPS origin of an external host page that embeds the app; can be specified multiple times. Replaces, rather than merges with, any hostDomains specified in the --definition-file.


Active voice (CLI convention). Use the standard repeat-the-flag phrasing instead of "can be specified multiple times."

Suggested change

HTTP or HTTPS origin of an external host page that embeds the app; can be specified multiple times. Replaces, rather than merges with, any hostDomains specified in the --definition-file.

HTTP or HTTPS origin of an external host page that embeds the app. Repeat the flag to specify more than one. Replaces, rather than merges with, any hostDomains in the --definition-file.

Done — applied verbatim: "…that embeds the app. Repeat the flag to specify more than one. Replaces, rather than merges with, any hostDomains in the --definition-file."

subashbabu-pixel · 2026-09-22T12:33:36Z

+
+# flags.components.summary
+
+Name of a Lightning web component exposed by the app; can be specified multiple times. Replaces, rather than merges with, any components specified in the --definition-file.


Active voice (CLI convention). Use the standard repeat-the-flag phrasing.

Suggested change

Name of a Lightning web component exposed by the app; can be specified multiple times. Replaces, rather than merges with, any components specified in the --definition-file.

Name of a Lightning web component exposed by the app. Repeat the flag to specify more than one. Replaces, rather than merges with, any components in the --definition-file.

Done — applied verbatim: "…exposed by the app. Repeat the flag to specify more than one. Replaces, rather than merges with, any components in the --definition-file."

subashbabu-pixel · 2026-09-22T12:33:37Z

+
+# flags.eca-name.summary
+
+Developer name of the External Client Application (OAuth) associated with the app.


Consistency. Drop the "(OAuth)" parenthetical so all three External Client Application flags read the same (line 57 doesn't use it).

Suggested change

Developer name of the External Client Application (OAuth) associated with the app.

Developer name of the External Client Application associated with the app.

Done — dropped "(OAuth)": "Developer name of the External Client Application associated with the app."

subashbabu-pixel · 2026-09-22T12:33:39Z

+
+# flags.eca-contact-email.summary
+
+Contact email for the External Client Application (OAuth).


Consistency. Match the other External Client Application flags by dropping "(OAuth)".

Suggested change

Contact email for the External Client Application (OAuth).

Contact email for the External Client Application.

Done — dropped "(OAuth)": "Contact email for the External Client Application."

…; gate CLWR frontdoor note

akashdhake · 2026-09-22T14:12:53Z

Thanks @srijanakde2001 and @subashbabu-pixel — all your comments are addressed in the latest push (message-file copy edits, plus the earlier definition-file type validation and the --api-version change). I've replied inline on each thread; feel free to resolve if it looks good, or re-open anything I missed.

aman06it

LGTM!

subashbabu-pixel

Thanks for turning these around. All the CX copy edits look good in the latest revision, tests and code comments are addressed, and the messages read cleanly.

salesforce-cla Bot added the cla:signed label Sep 7, 2026

akashdhake mentioned this pull request Sep 7, 2026

feat(lightning-out): add template generate lightning-out command #1045

Closed

akashdhake marked this pull request as ready for review September 8, 2026 15:25

akashdhake requested a review from a team as a code owner September 8, 2026 15:25

akashdhake mentioned this pull request Sep 8, 2026

feat(lightning-out): add Lightning Out 2.0 template generator @W-24035484@ forcedotcom/salesforcedx-templates#880

Merged

akashdhake force-pushed the lo2/lightning-out branch from a27248b to 9bde2a8 Compare September 9, 2026 08:55

akashdhake changed the title ~~feat(lightning-out): add template generate lightning-out command~~ feat(lightning-out): add template generate lightning-out command @W-24035498@ Sep 9, 2026

akashdhake and others added 9 commits September 11, 2026 21:49

feat: add template generate lightning-out command (Option A)

b3f7d49

Reads a JSON definition file and scaffolds the LO 2.0 metadata via @salesforce/templates. Always warns that the generated IframeWhiteListUrlSettings REPLACES the org's Trusted Domains list on deploy. Generate-only.

wip(lightning-out): checkpoint prior Option-A command edits before re…

f56dc98

…conciliation

feat(lightning-out): substitute output dir into deploy guidance

4312e7d

test(lightning-out): rewrite NUT for 7-artifact generate-only command

04793ff

test(lightning-out): cover readDefinition errors and api-version floo…

5413325

…r predicate

refactor(lightning-out): drop warnings consumption; regenerate schema…

21f81bc

…s without warnings field

fix(lightning-out): use repo Apache license header and drop redundant…

9050ac9

… flags cast

chore(deps): bump @salesforce/templates to ^66.16.0

06d5bb0

akashdhake force-pushed the lo2/lightning-out branch from 9bde2a8 to 06d5bb0 Compare September 11, 2026 16:25

jshackell-sfdc reviewed Sep 21, 2026

View reviewed changes

srijanakde2001 reviewed Sep 22, 2026

View reviewed changes

fix(lightning-out): address PR review — wording, def-file type valida…

5272b27

…tion, drop inert --api-version

subashbabu-pixel reviewed Sep 22, 2026

View reviewed changes

akashdhake added 2 commits September 22, 2026 18:13

fix(lightning-out): suggest --api-version only below the deploy floor…

c8a4317

…; gate CLWR frontdoor note

docs(lightning-out): apply reviewer copy edits to command messages

96f0fe1

aman06it approved these changes Sep 23, 2026

View reviewed changes

subashbabu-pixel approved these changes Sep 23, 2026

View reviewed changes

jshackell-sfdc approved these changes Sep 23, 2026

View reviewed changes

k80bowman approved these changes Sep 23, 2026

View reviewed changes


		# description

		Generates the seven metadata artifact types a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it does not deploy and never contacts an org.


		# summary

		Generate the metadata scaffold for a Lightning Out 2.0 application.

	Generate the metadata scaffold for a Lightning Out 2.0 application.
	Generate the required metadata to scaffold a Lightning Out 2.0 app.


		# flags.app-name.summary

		Metadata API name of the Lightning Out 2.0 app.

	Metadata API name of the Lightning Out 2.0 app.
	Developer name of the new Lightning Out 2.0 app.


		# flags.eca-name.summary

		Metadata API name of the External Client Application (OAuth) associated with the app.

	Metadata API name of the External Client Application (OAuth) associated with the app.
	Developer name of the External Client Application (OAuth) associated with the app.


		# flags.runtime.summary

		Runtime the app targets: LWR_CORE or CLWR. CLWR is experimental.

		@@ -0,0 +1,99 @@
		# examples

		- Generate from individual flags (discoverable via --help; the nested eca block is flattened into --eca-\* flags):

	- Generate from individual flags (discoverable via --help; the nested eca block is flattened into --eca-\* flags):
	- Generate a Lightning Out 2.0 app using individual flags to specify the values:


		<%= config.bin %> <%= command.id %> --app-name MyLoApp --runtime LWR_CORE --host-domains https://example.com --eca-name MyLoAppEca --eca-contact-email dev@example.com --eca-callback-url https://example.com/cb

		- Generate from a JSON definition file (like "sf org create scratch --definition-file", the whole input set — including the nested eca block — lives in one file):

	- Generate from a JSON definition file (like "sf org create scratch --definition-file", the whole input set — including the nested eca block — lives in one file):
	- Generate an app using the values in a JSON definition file called lo-def.json:


		<%= config.bin %> <%= command.id %> --definition-file lo-def.json

		- Generate into a specific directory:

	- Generate into a specific directory:
	- Generate the app into a specific directory:


		<%= config.bin %> <%= command.id %> --definition-file lo-def.json --output-dir force-app/main/default

		- Mix a definition file with an override flag (flags win over the file, per key):

	- Mix a definition file with an override flag (flags win over the file, per key):
	- Generate the app using most of the values from a definition file, but the --host-domains value overrides its equivalent in the file:


		Generates the seven metadata artifact types a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it does not deploy and never contacts an org.

		Inputs may come from a --definition-file JSON, individual flags, or both — flags take precedence over the file on a per-key basis. All structural validation (required fields, formats) is performed by the underlying generator.


		# description

		Lightning Out 2.0 is a Salesforce app that you use to embed custom Lightning web components (LWC) into your external, non-Salesforce apps.

	Lightning Out 2.0 is a Salesforce app that you use to embed custom Lightning web components (LWC) into your external, non-Salesforce apps.
	Lightning Out lets you embed custom Lightning web components (LWCs) into your external, non-Salesforce apps.


		Lightning Out 2.0 is a Salesforce app that you use to embed custom Lightning web components (LWC) into your external, non-Salesforce apps.

		This command gets you started by generating into your Salesforce DX project the seven metadata artifact types that a Lightning Out 2.0 app requires: LightningOutApp, MyDomain and Security settings, one CorsWhitelistOrigin per host domain, and the External Client Application OAuth trio (ExternalClientApplication, ExtlClntAppGlobalOauthSettings, ExtlClntAppOauthSettings). The command is generate-only; it doesn't deploy any metadata to an org.

Conversation

akashdhake commented Sep 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Command layer

Testing

Uh oh!

jshackell-sfdc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

srijanakde2001 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akashdhake commented Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akashdhake commented Sep 7, 2026 •

edited

Loading

akashdhake commented Sep 22, 2026 •

edited

Loading

subashbabu-pixel left a comment •

edited

Loading


		# flags.host-domains.summary

		HTTP or HTTPS origin of an external host page that embeds the app; can be specified multiple times. Replaces, rather than merges with, any hostDomains specified in the --definition-file.


		# flags.components.summary

		Name of a Lightning web component exposed by the app; can be specified multiple times. Replaces, rather than merges with, any components specified in the --definition-file.


		# flags.eca-contact-email.summary

		Contact email for the External Client Application (OAuth).