feat(lightning-out): @W-24501804@ promote command to GA and improve post-run guidance by akashdhake · Pull Request #1070 · salesforcecli/plugin-templates

akashdhake · 2026-10-15T13:16:31Z

Work item: W-24501804
https://gus.lightning.force.com/lightning/r/ADM_Work__c/a07EE00002nLhYnYAK/view

Summary

Promotes sf template generate lightning-out to GA and improves the guidance it prints after a run. All Setup wording was checked against Salesforce Core (266-main, and 264 for the Setup labels).

Changes

1. GA

Remove state = 'beta' and hidden = true, as in the ui-embedding GA promotion (2e3c440).

2. Wording cleanup

Replace the em dashes in success.app-id and success.dont-delete.
Use "Lightning Out 2.0" in the success text, per the naming guidance until the beta is sunset.

3. CLWR: link the app to a site

A Metadata API deploy creates no site link. The link is created when you save on the "Linked Communities Site" tab of the app in Lightning Out 2.0 App Manager, and the CLWR runtime finds an app's components through it.
--runtime help said only "extra site-deployment step". Its summary is now one line, and the detail moved to a new flags.runtime.description.
New success.clwr-site, printed for CLWR only, right after the deploy command.

4. Org-wide settings warning

The generated MyDomain and Security settings set isFirstPartyCookieUseRequired=false and enableOauthCorsPolicy=true for the whole org. Nothing in the output said so.
New warning.org-settings, printed before the deploy command for every run. It is a warning, so it also appears in the warnings array of --json output. That is deliberate.

5. App ID guidance

success.app-id now says where to find the App ID (Lightning Out 2.0 App Manager in Setup) and to set it as the app-id attribute on <lightning-out-application>, and that without it the host domains aren't added to the CSP frame-ancestors directive.
It is printed for LWR_CORE only. app-id has no effect on CLWR, which finds the app through the site link (item 3).

6. Removed success.frontdoor

It applied only to authenticated CLWR and named no attributes. CLWR host pages now get a short site-prefix line and a pointer to the developer guide instead (item 7); the full host-page setup stays in the docs.

7. Copy review follow-up

Applied the CX copy review: shorter --runtime summary, a CLWR CORS-only note on --host-domains, Setup labels in the org-settings warning, and consistent "External Client Application" naming.
success.app-id now gives the Quick Find path and says the browser blocks the app without it.
success.clwr-site now tells CLWR host pages to set site-prefix (required, or requests fall back to the LWR flow) and points to the developer guide.
success.components-exist now prints before the deploy command, since it's a pre-deploy check.
Added a CLWR example to --help.

Testing

Unit tests: 35 passing in the lightning-out test file. The new tests run the command with the generator stubbed and check that the CLWR site-link guidance is shown only for CLWR, the App ID line only for LWR_CORE, and the org-wide warning for every runtime. A test also checks that the component check prints before the deploy command.
Ran the real sf (linked build) for CLWR, LWR_CORE and --json; output matches the above, and --json carries only the org-settings warning.
yarn test (wireit): passes.
yarn lint: 0 errors. 1 existing warning (sf-plugin/get-connection-with-version in digital-experience/site.ts), not from this change.
--help output checked for the new --runtime text, the CLWR note on --host-domains, and the CLWR example.
NUTs (lightning-out/index.nut.ts): 8 passing.
Not run: an end-to-end run against an org. Guest and authenticated CLWR access were checked separately during the spike on a local Core org.

Notes

command-snapshot.json doesn't record state or hidden, and no flags were added or removed, so it needs no change.
CHANGELOG and the README command list are generated at release time, so I didn't touch them.
This replaces the earlier split into feat(lightning-out): @W-24501804@ promote command to GA and improve post-run guidance #1070 and feat(lightning-out): @W-24501804@ add CLWR site link, org-wide settings and App ID guidance #1071. Everything is now in this PR.

Copy review

Done by @subashbabu-pixel. All comments are applied in f0498f1 (item 7), and each thread has a reply.

Known gaps, not in this PR

--host-domains doesn't affect how a CLWR app is framed. On CLWR, host domains only set CORS (used by authenticated users). Framing is set on the site in Experience Builder.

…ost-run guidance

subashbabu-pixel

CX copy review: messages/lightningOut.md

The copy reads well, and routing each message by runtime is a good improvement. Two items need confirming before merge (guest wording on line 45, CLWR host-page guidance in index.ts). The rest are copy suggestions you can commit directly.

Optional: add a CLWR example to # examples, since the command becomes public at GA, for example <%= config.bin %> <%= command.id %> --runtime CLWR --definition-file lo-def.json.

subashbabu-pixel · 2026-10-21T09:08:31Z

 # flags.runtime.summary

-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).
+Runtime the app targets: LWR_CORE or CLWR.


oclif already prints <options: LWR_CORE|CLWR>, so the summary doesn't need to list them.

Suggested change

Runtime the app targets: LWR_CORE or CLWR.

Runtime that serves the app.

Done, thanks.

subashbabu-pixel · 2026-10-21T09:08:31Z

+
+# flags.runtime.description
+
+LWR_CORE serves the app from your Salesforce org to authenticated users. CLWR serves it from an Experience Cloud site to guest and authenticated users. After you deploy a CLWR app, link it to your site in Setup.


Please keep "guest and authenticated users." PM confirmed that CLWR supports guest access. Could you settle the conflicting answer mentioned in the PR notes with PM before merge, so the CLI and the docs say the same thing?

Agreed. PM confirmed, and guest access is verified in an org, so I've removed the conflicting note from Known gaps. One thing for the help topic: in our testing, guest access needed the site (or the /lightning-out page) set to public, and then a republish.

subashbabu-pixel · 2026-10-21T09:08:31Z

+
+LWR_CORE serves the app from your Salesforce org to authenticated users. CLWR serves it from an Experience Cloud site to guest and authenticated users. After you deploy a CLWR app, link it to your site in Setup.

 # flags.host-domains.summary


If CLWR ignores --host-domains (listed under Known gaps), consider adding "Applies to LWR_CORE apps only." to this summary. Otherwise CLWR users will set the flag and expect it to work. (The summary line itself isn't in the diff, so this comment is on the heading.)

I added a note, but not "LWR_CORE only". The flag is still required for CLWR, and the generator creates CORS entries from it, which authenticated CLWR needs. The summary now says host domains are used only for CORS on CLWR, and that framing is set on the site in Experience Builder.

subashbabu-pixel · 2026-10-21T09:08:31Z


+# warning.org-settings
+
+The generated MyDomain and Security settings apply to the whole org when you deploy them: isFirstPartyCookieUseRequired is set to false and enableOauthCorsPolicy is set to true. Review both settings before deploying to a production org.


Admins know these settings by their Setup labels, not their field names, and the warning should say why the change matters. Please verify both labels against Setup.

Suggested change

The generated MyDomain and Security settings apply to the whole org when you deploy them: isFirstPartyCookieUseRequired is set to false and enableOauthCorsPolicy is set to true. Review both settings before deploying to a production org.

Deploying the generated MyDomain and Security settings changes two org-wide settings: isFirstPartyCookieUseRequired is set to false (Require first-party use of Salesforce cookies) and enableOauthCorsPolicy is set to true (Enable CORS for OAuth endpoints). These settings affect every app in the org, so review them before you deploy to a production org.

Done. Both labels match Setup.

subashbabu-pixel · 2026-10-21T09:08:31Z

 # success.app-id

-After deploying, note the LightningOutApp's App ID from Setup — your host page needs it to embed the app.
+After deploying, copy the App ID from Lightning Out 2.0 App Manager in Setup, and set it as the "app-id" attribute on the <lightning-out-application> tag on your host page. Without it, your host domains aren't added to the CSP frame-ancestors directive.


This adds what the user will actually see. Also consider adding the Quick Find path that success.clwr-site uses, so the two messages match.

Suggested change

After deploying, copy the App ID from Lightning Out 2.0 App Manager in Setup, and set it as the "app-id" attribute on the <lightning-out-application> tag on your host page. Without it, your host domains aren't added to the CSP frame-ancestors directive.

After deploying, copy the App ID from Lightning Out 2.0 App Manager in Setup, and set it as the "app-id" attribute on the <lightning-out-application> tag on your host page. Without it, your host domains aren't added to the CSP frame-ancestors directive, and the browser blocks the app from loading on your host page.

Done. I also added the Quick Find path, so it matches success.clwr-site.

subashbabu-pixel · 2026-10-21T09:08:31Z

 # success.dont-delete

-Don't delete the generated ExternalClientApplication after deploying — Lightning Out uses it for OAuth at runtime.
+Don't delete the generated ExternalClientApplication after deploying. Lightning Out 2.0 uses it for OAuth at runtime.


This matches "External Client Application" in eca-overwrite and the flag summaries.

Suggested change

Don't delete the generated ExternalClientApplication after deploying. Lightning Out 2.0 uses it for OAuth at runtime.

Don't delete the generated External Client Application after deploying. Lightning Out 2.0 uses it for OAuth at runtime.

Done, thanks.

subashbabu-pixel · 2026-10-21T09:08:31Z


 # success.eca-overwrite

 Re-running this command overwrites the generated files for the "%s" External Client Application; back up local edits first.


Two short sentences read better in terminal output than one joined by a semicolon.

Suggested change

Re-running this command overwrites the generated files for the "%s" External Client Application; back up local edits first.

Re-running this command overwrites the generated files for the "%s" External Client Application. Back up local edits first.

Done, thanks.

subashbabu-pixel · 2026-10-21T09:08:31Z

+# success.clwr-site

-For CLWR, host pages must complete a frontdoor.jsp handoff before the embedded app can authenticate.
+For CLWR, link the app to your Experience Cloud site after deploying. From Setup, in the Quick Find box, enter Lightning Out, and then select Lightning Out 2.0 App Manager. Edit the app, select your site on the "Linked Communities Site" tab, and save. Then follow the steps in the "Complete Deployment in Experience Builder" dialog, which include publishing the site.


This message is only printed for CLWR, so "For CLWR," isn't needed. The labels are also formatted inconsistently (two are quoted, App Manager isn't), so this quotes all three UI labels.

Suggested change

For CLWR, link the app to your Experience Cloud site after deploying. From Setup, in the Quick Find box, enter Lightning Out, and then select Lightning Out 2.0 App Manager. Edit the app, select your site on the "Linked Communities Site" tab, and save. Then follow the steps in the "Complete Deployment in Experience Builder" dialog, which include publishing the site.

Link the app to your Experience Cloud site after deploying. From Setup, in the Quick Find box, enter Lightning Out, and then select "Lightning Out 2.0 App Manager". Edit the app, select your site on the "Linked Communities Site" tab, and save. Then follow the steps in the "Complete Deployment in Experience Builder" dialog, which include publishing the site.

Done, thanks.

subashbabu-pixel · 2026-10-21T09:08:31Z

-    this.info(messages.getMessage('success.app-id'));
+    // CLWR finds the app through the site link; app-id only applies to LWR_CORE.
+    if (opts.runtime === 'CLWR') {
+      this.info(messages.getMessage('success.clwr-site'));


With success.frontdoor removed, CLWR runs now print nothing about the host page, while LWR_CORE gets the app-id line. Do CLWR host pages need to set site-prefix on <lightning-out-application>? If so, it's worth a line. Either way, consider a pointer such as "For host-page setup, see the Lightning Out 2.0 Developer Guide."

Follow-up: confirmed that site-prefix is still required on CLWR host pages. Without it, requests fall back to the LWR flow. Suggest adding a sentence to the end of success.clwr-site:

On your host page, set the "site-prefix" attribute on the tag to your site's URL prefix.

Please double-check the wording against the developer guide.

Added the site-prefix sentence with an example ("/mysite"), plus a plain-text pointer: see "Lightning Out 2.0" in the Lightning Web Components Developer Guide. Can you confirm the right section title to cite?

Cite "Use Components Outside Salesforce with Lightning Out 2.0" in the LWC Developer Guide. That's the top-level Lightning Out 2.0 section. The <lightning-out-application> attributes and host-page markup are in its "Understand Lightning Out 2.0 Architecture" page, if you'd rather point there directly.

Done in d0cb551, using "Use Components Outside Salesforce with Lightning Out 2.0". Thanks!

subashbabu-pixel · 2026-10-21T09:08:31Z

    this.log(messages.getMessage('success.next-step', [outputDir, shellQuoteArg(outputDir), apiVersionSuffix]));
-    this.info(messages.getMessage('success.app-id'));
+    // CLWR finds the app through the site link; app-id only applies to LWR_CORE.
+    if (opts.runtime === 'CLWR') {
+      this.info(messages.getMessage('success.clwr-site'));
+    } else {
+      this.info(messages.getMessage('success.app-id'));
+    }
    this.info(messages.getMessage('success.dont-delete'));
    this.info(messages.getMessage('success.eca-overwrite', [opts.eca.name ?? '']));
    this.info(messages.getMessage('success.components-exist'));


Output order: success.components-exist says "before deploying" but prints last, after the post-deploy steps. This moves it above the deploy command, so pre-deploy checks come first, then the deploy command, then the post-deploy steps. (The org-settings warning already prints before the deploy command.)

Suggested change

this.log(messages.getMessage('success.next-step', [outputDir, shellQuoteArg(outputDir), apiVersionSuffix]));

this.info(messages.getMessage('success.app-id'));

// CLWR finds the app through the site link; app-id only applies to LWR_CORE.

if (opts.runtime === 'CLWR') {

this.info(messages.getMessage('success.clwr-site'));

} else {

this.info(messages.getMessage('success.app-id'));

}

this.info(messages.getMessage('success.dont-delete'));

this.info(messages.getMessage('success.eca-overwrite', [opts.eca.name ?? '']));

this.info(messages.getMessage('success.components-exist'));

this.info(messages.getMessage('success.components-exist'));

this.log(messages.getMessage('success.next-step', [outputDir, shellQuoteArg(outputDir), apiVersionSuffix]));

// CLWR finds the app through the site link; app-id only applies to LWR_CORE.

if (opts.runtime === 'CLWR') {

this.info(messages.getMessage('success.clwr-site'));

} else {

this.info(messages.getMessage('success.app-id'));

}

this.info(messages.getMessage('success.dont-delete'));

this.info(messages.getMessage('success.eca-overwrite', [opts.eca.name ?? '']));

Done. The component check now prints before the deploy command, and a new test checks the order.

…ance Apply the CX copy review from PR salesforcecli#1070: - Shorter runtime summary; CLWR CORS-only note on --host-domains. - Setup labels in the org-settings warning. - Quick Find path and impact in app-id; site-prefix and guide pointer for CLWR. - Consistent External Client Application naming; add a CLWR example. - Print the pre-deploy component check before the deploy command, with a test.

akashdhake · 2026-10-21T11:21:20Z

Thanks for the review, @subashbabu-pixel. All comments are addressed in f0498f1, including the optional CLWR example in # examples. Replies are on each thread. Could you take another look?

subashbabu-pixel

Approved. All comments from the first pass are applied. Thanks, Akash!

Two optional nits on lines this PR doesn't change, so GitHub can't attach suggestions to them. Neither blocks merge:

messages/lightningOut.md line 31: "The command is generate-only; it doesn't deploy any metadata to an org." → "The command only generates files. It doesn't deploy any metadata to an org."
messages/lightningOut.md line 33: "Inputs may come from a --definition-file JSON, individual flags, or both." → "Inputs can come from a --definition-file JSON, individual flags, or both."

akashdhake · 2026-10-26T09:09:36Z

Thanks for the approval, @subashbabu-pixel! Applied both optional nits in 476da29:

"The command only generates files. It doesn't deploy any metadata to an org."
"Inputs can come from a --definition-file JSON, individual flags, or both."

akashdhake requested a review from a team as a code owner October 15, 2026 13:16

salesforce-cla Bot added the cla:signed label Oct 15, 2026

akashdhake mentioned this pull request Oct 15, 2026

feat(lightning-out): @W-24501804@ add CLWR site link, org-wide settings and App ID guidance #1071

Closed

akashdhake changed the title ~~feat(lightning-out): @W-24501804@ promote command to GA and polish success messages~~ feat(lightning-out): @W-24501804@ promote command to GA and improve post-run guidance Oct 15, 2026

feat(lightning-out): @W-24501804@ promote command to GA and improve p…

99eeb2a

…ost-run guidance

akashdhake force-pushed the feat/lightning-out-ga branch from daaec59 to 99eeb2a Compare October 16, 2026 04:53

subashbabu-pixel reviewed Oct 21, 2026

View reviewed changes

fix(lightning-out): @W-24501804@ cite LWC dev guide section title

d0cb551

subashbabu-pixel approved these changes Oct 26, 2026

View reviewed changes

fix(lightning-out): @W-24501804@ apply optional copy nits from review

476da29

	Runtime the app targets: LWR_CORE or CLWR.
	Runtime that serves the app.


		# flags.runtime.description

		LWR_CORE serves the app from your Salesforce org to authenticated users. CLWR serves it from an Experience Cloud site to guest and authenticated users. After you deploy a CLWR app, link it to your site in Setup.


		LWR_CORE serves the app from your Salesforce org to authenticated users. CLWR serves it from an Experience Cloud site to guest and authenticated users. After you deploy a CLWR app, link it to your site in Setup.

		# flags.host-domains.summary


		# warning.org-settings

		The generated MyDomain and Security settings apply to the whole org when you deploy them: isFirstPartyCookieUseRequired is set to false and enableOauthCorsPolicy is set to true. Review both settings before deploying to a production org.

	The generated MyDomain and Security settings apply to the whole org when you deploy them: isFirstPartyCookieUseRequired is set to false and enableOauthCorsPolicy is set to true. Review both settings before deploying to a production org.
	Deploying the generated MyDomain and Security settings changes two org-wide settings: isFirstPartyCookieUseRequired is set to false (Require first-party use of Salesforce cookies) and enableOauthCorsPolicy is set to true (Enable CORS for OAuth endpoints). These settings affect every app in the org, so review them before you deploy to a production org.

	After deploying, copy the App ID from Lightning Out 2.0 App Manager in Setup, and set it as the "app-id" attribute on the <lightning-out-application> tag on your host page. Without it, your host domains aren't added to the CSP frame-ancestors directive.
	After deploying, copy the App ID from Lightning Out 2.0 App Manager in Setup, and set it as the "app-id" attribute on the <lightning-out-application> tag on your host page. Without it, your host domains aren't added to the CSP frame-ancestors directive, and the browser blocks the app from loading on your host page.

	Don't delete the generated ExternalClientApplication after deploying. Lightning Out 2.0 uses it for OAuth at runtime.
	Don't delete the generated External Client Application after deploying. Lightning Out 2.0 uses it for OAuth at runtime.


		# success.eca-overwrite

		Re-running this command overwrites the generated files for the "%s" External Client Application; back up local edits first.

	For CLWR, link the app to your Experience Cloud site after deploying. From Setup, in the Quick Find box, enter Lightning Out, and then select Lightning Out 2.0 App Manager. Edit the app, select your site on the "Linked Communities Site" tab, and save. Then follow the steps in the "Complete Deployment in Experience Builder" dialog, which include publishing the site.
	Link the app to your Experience Cloud site after deploying. From Setup, in the Quick Find box, enter Lightning Out, and then select "Lightning Out 2.0 App Manager". Edit the app, select your site on the "Linked Communities Site" tab, and save. Then follow the steps in the "Complete Deployment in Experience Builder" dialog, which include publishing the site.

Conversation

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

Uh oh!

Summary

Changes

Testing

Notes

Copy review

Known gaps, not in this PR

Uh oh!

subashbabu-pixel 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!

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 Oct 21, 2026

Uh oh!

subashbabu-pixel left a comment

Choose a reason for hiding this comment

Uh oh!

akashdhake commented Oct 26, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

akashdhake commented Oct 15, 2026 •

edited

Loading