From ce02b4326af7b1b924feff56a7063869e3425716 Mon Sep 17 00:00:00 2001 From: Randi Wilson Date: Wed, 3 Aug 2022 18:26:16 -0400 Subject: [PATCH] docs: 2022 docs cleanup --- .vscode/launch.json | 2 +- contributing/developing.md | 17 +++++++++++------ contributing/publishing.md | 8 +------- 3 files changed, 13 insertions(+), 14 deletions(-) diff --git a/.vscode/launch.json b/.vscode/launch.json index 8715aae0..cb16cd82 100644 --- a/.vscode/launch.json +++ b/.vscode/launch.json @@ -7,7 +7,7 @@ { "type": "node", "request": "attach", - "name": "Attach", + "name": "Attach to Remote", "port": 9229, "skipFiles": ["/**"] }, diff --git a/contributing/developing.md b/contributing/developing.md index ef64b315..5bd976e2 100644 --- a/contributing/developing.md +++ b/contributing/developing.md @@ -36,24 +36,29 @@ yarn build 1. based on `main` and will be 1. squash-merged into `main`. -- Hot-fix branches are an exception. - - Instead we aim for faster cycles and a generally stable `develop` branch. - ### Making Pull Requests Take a look at [CONTRIBUTING](../CONTRIBUTING.md) doc for making and merging pull requests. ## Developing Plugin -To test plugin locally, use `bin/run` in place of `sfdx`. For example: +To test the plugin locally, you have a few options. + +# Option 1: Run the command from the bin/run directory + +From within the Templates project, use `bin/run` in place of `sfdx` from within the `plugin-templates` package. For example: ```sh ./bin/run force:apex:class:create --classname 'TestClass' --template 'DefaultApexClass' --outputdir ./testsoutput/myApex/ ``` -To test plugin locally with Salesforce CLI, add `"@salesforce/templates": "file://path/to/packages/templates"` to the plugin's `package.json`. +# Option 2: Update your project's Templates reference + +If your project calls the `templates` package directly, you can add `"@salesforce/templates": "file://absolute/path/to/salesforcedx-templates/packages/templates"` to the plugin's `package.json`. Re-install dependencies to pull in the local files. + +# Option 3: Update your CLI -Link your plugin to Salesforce CLI: +Finally, you can link your plugin to Salesforce CLI, so that when the command is invoked from the CLI, it will use your local plugin. From the top level of salesforcedx-templates: ```sh sfdx plugins:link . diff --git a/contributing/publishing.md b/contributing/publishing.md index ebda582a..25f4a9c0 100644 --- a/contributing/publishing.md +++ b/contributing/publishing.md @@ -9,15 +9,9 @@ Every PR merge to main gets published automatically and goes through a minor ver 1. Publisher has a valid CircleCI token for the forcedotcom organization. More info on CircleCI's doc [Create a Personal API token](https://circleci.com/docs/2.0/managing-api-tokens/#creating-a-personal-api-token). 1. Publisher is a part of the GitHub team 'PDT'. -## Background - -After feature/bug work has been QA'd and closed, it's time to prepare those changes for publishing. - -The salesforcedx-templates project uses a two-branch strategy. Work that is currently under development is committed to the 'develop' branch. The 'main' branch is what's currently in production or is being staged for production. - ## Publishing to NPM -To publish the changes to npm, we run the task `Publish Library and Plugin`. This task calls the script `publish-workflow.sh` and prompts the user for the required information. The publish-workflow script generates an HTTP Request to the CircleCI API. It tells CircleCI that it wants to run the `publish-workflow` from the `main` branch. +To publish the changes manually to npm, we run the task `Publish Library and Plugin`. This task calls the script `publish-workflow.sh` and prompts the user for the required information. The publish-workflow script generates an HTTP Request to the CircleCI API. It tells CircleCI that it wants to run the `publish-workflow` from the `main` branch. ### Publish a major or patch release version