diff --git a/.github/workflows/create-github-release.yml b/.github/workflows/create-github-release.yml index 570faeb1..2021e825 100644 --- a/.github/workflows/create-github-release.yml +++ b/.github/workflows/create-github-release.yml @@ -1,12 +1,12 @@ name: create-github-release on: -# push: -# branches: -# - main -# - prerelease/** -# tags-ignore: -# - '*' + push: + branches: + - main + - prerelease/** + tags-ignore: + - '*' workflow_dispatch: inputs: prerelease: diff --git a/PLUGIN_TEMPLATE.md b/PLUGIN_TEMPLATE.md new file mode 100644 index 00000000..dba82825 --- /dev/null +++ b/PLUGIN_TEMPLATE.md @@ -0,0 +1,37 @@ +## Using the template + +This repository provides a template for creating a plugin for the Salesforce CLI. To convert this template to a working plugin: + +1. Please get in touch with the Platform CLI team. We want to help you develop your plugin. +2. Generate your plugin: + + ``` + sf plugins install dev + sf dev generate plugin + + git init -b main + git add . && git commit -m "chore: initial commit" + ``` + +3. Create your plugin's repo in the salesforcecli github org +4. When you're ready, replace the contents of this README with the information you want. + +## Learn about `sf` plugins + +Salesforce CLI plugins are based on the [oclif plugin framework](https://oclif.io/docs/introduction). Read the [plugin developer guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins_architecture_sf_cli.htm) to learn about Salesforce CLI plugin development. + +This repository contains a lot of additional scripts and tools to help with general Salesforce node development and enforce coding standards. You should familiarize yourself with some of the [node developer packages](#tooling) used by Salesforce. There is also a default circleci config using the [release management orb](https://github.com/forcedotcom/npm-release-management-orb) standards. + +Additionally, there are some additional tests that the Salesforce CLI will enforce if this plugin is ever bundled with the CLI. These test are included by default under the `posttest` script and it is required to keep these tests active in your plugin if you plan to have it bundled. + +### Tooling + +- [@salesforce/core](https://github.com/forcedotcom/sfdx-core) +- [@salesforce/kit](https://github.com/forcedotcom/kit) +- [@salesforce/sf-plugins-core](https://github.com/salesforcecli/sf-plugins-core) +- [@salesforce/ts-types](https://github.com/forcedotcom/ts-types) +- [@salesforce/ts-sinon](https://github.com/forcedotcom/ts-sinon) +- [@salesforce/dev-config](https://github.com/forcedotcom/dev-config) +- [@salesforce/dev-scripts](https://github.com/forcedotcom/dev-scripts) + +# Everything past here is only a suggestion as to what should be in your specific plugin's description diff --git a/README.md b/README.md index 938aaf6f..c4795699 100644 --- a/README.md +++ b/README.md @@ -1,86 +1,7 @@ -**NOTE: This template for sf plugins is not yet official. Please consult with the Platform CLI team before using this template.** - # plugin-lightning-dev [![NPM](https://img.shields.io/npm/v/@salesforce/plugin-lightning-dev.svg?label=@salesforce/plugin-lightning-dev)](https://www.npmjs.com/package/@salesforce/plugin-lightning-dev) [![Downloads/week](https://img.shields.io/npm/dw/@salesforce/plugin-lightning-dev.svg)](https://npmjs.org/package/@salesforce/plugin-lightning-dev) [![License](https://img.shields.io/badge/License-BSD%203--Clause-brightgreen.svg)](https://raw.githubusercontent.com/salesforcecli/plugin-lightning-dev/main/LICENSE.txt) -## Setup - -Prereqs: - -1. Setup an Experience Site and publish it - -2. Run the following: - -```bash -yarn && yarn build -yarn link-lwr -sf org login web --instance-url ${orgfarmUrl} -``` - -## Run the command - -Then run the following for your environment: - -```bash -./bin/dev.js lightning dev site -``` - -or for debugging: - -```bash -NODE_OPTIONS='--inspect-brk' ./bin/dev.js lightning dev site -``` - -No need to recompile or watch typescript files as this happens automagically. - -## Fix Snapshots - -```bash -node --loader ts-node/esm --no-warnings=ExperimentalWarning ./bin/dev.js snapshot:compare -node --loader ts-node/esm --no-warnings=ExperimentalWarning ./bin/dev.js schema:compare -yarn && yarn build -yarn update-snapshots -``` - -## Using the template - -This repository provides a template for creating a plugin for the Salesforce CLI. To convert this template to a working plugin: - -1. Please get in touch with the Platform CLI team. We want to help you develop your plugin. -2. Generate your plugin: - - ``` - sf plugins install dev - sf dev generate plugin - - git init -b main - git add . && git commit -m "chore: initial commit" - ``` - -3. Create your plugin's repo in the salesforcecli github org -4. When you're ready, replace the contents of this README with the information you want. - -## Learn about `sf` plugins - -Salesforce CLI plugins are based on the [oclif plugin framework](https://oclif.io/docs/introduction). Read the [plugin developer guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins_architecture_sf_cli.htm) to learn about Salesforce CLI plugin development. - -This repository contains a lot of additional scripts and tools to help with general Salesforce node development and enforce coding standards. You should familiarize yourself with some of the [node developer packages](#tooling) used by Salesforce. There is also a default circleci config using the [release management orb](https://github.com/forcedotcom/npm-release-management-orb) standards. - -Additionally, there are some additional tests that the Salesforce CLI will enforce if this plugin is ever bundled with the CLI. These test are included by default under the `posttest` script and it is required to keep these tests active in your plugin if you plan to have it bundled. - -### Tooling - -- [@salesforce/core](https://github.com/forcedotcom/sfdx-core) -- [@salesforce/kit](https://github.com/forcedotcom/kit) -- [@salesforce/sf-plugins-core](https://github.com/salesforcecli/sf-plugins-core) -- [@salesforce/ts-types](https://github.com/forcedotcom/ts-types) -- [@salesforce/ts-sinon](https://github.com/forcedotcom/ts-sinon) -- [@salesforce/dev-config](https://github.com/forcedotcom/dev-config) -- [@salesforce/dev-scripts](https://github.com/forcedotcom/dev-scripts) - -# Everything past here is only a suggestion as to what should be in your specific plugin's description - This plugin is bundled with the [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli). For more information on the CLI, read the [getting started guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm). We always recommend using the latest version of these commands bundled with the CLI, however, you can install a specific version or tag if needed. @@ -91,6 +12,12 @@ We always recommend using the latest version of these commands bundled with the sf plugins install @salesforce/plugin-lightning-dev@x.y.z ``` +or + +```bash +sf plugins install @salesforce/plugin-lightning-dev +``` + ## Issues Please report any issues at https://github.com/forcedotcom/cli/issues @@ -142,45 +69,181 @@ sf plugins link . sf plugins ``` +## LWR Sites Development Environment + +Follow these instructions if you want to setup a dev environment for the `sf lightning dev site` command. + +## Setup + +1. [Enable Local Development] (https://developer.salesforce.com/docs/platform/lwc/guide/get-started-test-components.html#enable-local-dev) + +2. Deploy some source files to your org from your SFDX project + +```bash +sf org login web --alias dev --instance-url ${orgfarmUrl} + +``` + +3. Add those source files to an LWR site in the Experience Builder and Publish the site (basePath: '/') + +4. Follow the [Build the plugin locally](#build) instructions + +5. [optional] Linking / Debugging LWR Source + +```bash +# build and link lwr source +cd lwr +yarn && yarn link-lwr + +# build and link plugin-lightning-dev source +cd plugin-lightning-dev +yarn && yarn build +yarn link-lwr + +# SFDX Project +cd sfdx-project + +# Login to your org +sf org login web --alias dev --instance-url https://login.test1.pc-rnd.salesforce.com/ (orgfarm needs instance url) + +# run/debug the sf cli command (attach to the CLI from the LWR repo in VS Code) +NODE_OPTIONS="--inspect-brk" sf lightning dev site --target-org dev +``` + +Now you can Remote Attach to the CLI from the vscode debugger: + +- Use the "Attach" launch configuration +- Run launch config from LWR repo if you want to debug LWR source +- Run launch config from plugin-lightning-dev source if you want to debug the SFDX plugin source specifically + +If this doesn't work for whatever reason, you can always alias the build output directly like so: + +```bash +alias sfdev="/{pathToGitDir}/plugin-lightning-dev/bin/run.js" +# SFDX Project +NODE_OPTIONS="--inspect-brk" sfdev lightning dev site --target-org dev +``` + +6. Make changes to your c-namespace components and you should see the browser refresh with those changes! + +## Fixing Snapshots + +```bash +node --loader ts-node/esm --no-warnings=ExperimentalWarning ./bin/dev.js snapshot:compare +node --loader ts-node/esm --no-warnings=ExperimentalWarning ./bin/dev.js schema:compare +yarn && yarn build +yarn update-snapshots +``` + ## Commands -- [`sf hello world`](#sf-hello-world) +- [`sf lightning dev app`](#sf-lightning-dev-app) +- [`sf lightning dev site`](#sf-lightning-dev-site) -## `sf hello world` +## `sf lightning dev app` -Say hello. +Preview a Lightning Experience app locally and in real-time, without deploying it. ``` USAGE - $ sf hello world [--json] [--flags-dir ] [-n ] + $ sf lightning dev app -o [--flags-dir ] [-n ] [-t desktop|ios|android] [-i ] FLAGS - -n, --name= [default: World] The name of the person you'd like to say hello to. + -i, --device-id= ID of the mobile device to display the preview if device type is set to `ios` or + `android`. The default value is the ID of the first available mobile device. + -n, --name= Name of the Lightning Experience app to preview. + -o, --target-org= (required) Username or alias of the target org. Not required if the `target-org` + configuration variable is already set. + -t, --device-type=