Repository: forcedotcom/cli Branch: main Commit: e6377d39c920 Files: 50 Total size: 864.9 KB Directory structure: gitextract_q88b20da/ ├── .git2gus/ │ └── config.json ├── .gitattributes ├── .github/ │ ├── ISSUE_TEMPLATE/ │ │ ├── bug_report.md │ │ └── config.yml │ ├── actions/ │ │ ├── new-issue/ │ │ │ ├── action.yml │ │ │ ├── lib/ │ │ │ │ ├── index.d.ts │ │ │ │ └── index.js │ │ │ ├── src/ │ │ │ │ └── index.ts │ │ │ └── tsconfig.json │ │ └── validate-issue/ │ │ ├── action.yml │ │ ├── lib/ │ │ │ ├── index.d.ts │ │ │ ├── index.js │ │ │ ├── nodeVersions.d.ts │ │ │ └── nodeVersions.js │ │ ├── messages/ │ │ │ ├── deprecated-cli.md │ │ │ ├── old-cli.md │ │ │ ├── provide-version.md │ │ │ └── unsupported-node.md │ │ ├── mock/ │ │ │ └── sample-context.json │ │ ├── src/ │ │ │ ├── index.ts │ │ │ └── nodeVersions.ts │ │ └── tsconfig.json │ └── workflows/ │ ├── closeStaleIssues.yml │ ├── issue-updated.yml │ └── new-label.yml ├── .gitignore ├── CHANGELOG.md ├── CODEOWNERS ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.txt ├── README.md ├── SECURITY.md ├── package.json ├── releasenotes/ │ ├── README.md │ ├── sf/ │ │ └── README.md │ ├── sfdx/ │ │ ├── README.md │ │ ├── v41.md │ │ ├── v42.md │ │ ├── v43.md │ │ ├── v44.md │ │ ├── v45.md │ │ ├── v46.md │ │ ├── v47.md │ │ ├── v48.md │ │ ├── v49.md │ │ └── v50.md │ ├── v49.md │ └── v50.md └── tsconfig.json ================================================ FILE CONTENTS ================================================ ================================================ FILE: .git2gus/config.json ================================================ { "productTag": "a1aB00000004Bx8IAE", "productTagLabels": { "area:afdx": "a1aEE000001vDZRYA2" }, "defaultBuild": "offcore.tooling.66", "issueTypeLabels": { "feature": "USER STORY", "regression": "BUG P1", "bug": "BUG P3" }, "hideWorkItemUrl": true, "statusWhenClosed": "CLOSED", "issueEpicMapping": { "BUG P1": "a3QB00000004yR1MAI", "BUG P3": "a3QB00000004yR1MAI" } } ================================================ FILE: .gitattributes ================================================ .github/actions/**/lib/* linguist-generated=true ================================================ FILE: .github/ISSUE_TEMPLATE/bug_report.md ================================================ --- name: Bug report about: Create a report to help us improve title: '' labels: 'investigating' assignees: '' --- > **Note** > Before you submit your issue, make sure that: > - You're using the latest version of Salesforce CLI. > - You've searched both open and closed issues for related posts. > - You've used the `doctor` command to diagnose common issues. > - You understand that GitHub Issues don't adhere to any agreement or SLA. > - If you require immediate assistance, use official channels such as Salesforce Customer Support. ### Summary ### Steps To Reproduce > **IMPORTANT** > Provide a repository that's configured to reproduce the issue. If you are unable to provide a repo, please explain why not. The more info we have from the start, the faster we can resolve your issue. > We may close your issue if you don't include proper instructions. > > - Generate a project with `sf project generate` or fork [dreamhouse-lwc](https://github.com/trailheadapps/dreamhouse-lwc). > - Provide detailed step-by-step instructions on how to reproduce the issue. > [!TIP] > use `sf doctor --create-issue` to automatically fill the required information ### Expected result ### Actual result ### Additional information ### System Information ```json PASTE_VERSION_OUTPUT_HERE ``` ================================================ FILE: .github/ISSUE_TEMPLATE/config.yml ================================================ blank_issues_enabled: false contact_links: - name: Salesforce DX Community url: https://success.salesforce.com/issues_index?tag=Salesforce%20DX about: Please ask and answer questions here. - name: Feature request url: https://github.com/forcedotcom/cli/discussions/new?category=ideas about: Feature requests should be opened as discussions ================================================ FILE: .github/actions/new-issue/action.yml ================================================ name: "Salesforce CLI Issues Bot" description: "Preform automatic responses to github issues." author: "Lisa Morgan" inputs: repo-token: required: true description: "Token taken from secrets env var" message: required: true description: "Message to post in issue comment" label: required: false description: "A label the issue must contain to post the message" runs: using: "node20" main: "lib/index.js" ================================================ FILE: .github/actions/new-issue/lib/index.d.ts ================================================ export {}; ================================================ FILE: .github/actions/new-issue/lib/index.js ================================================ "use strict"; Object.defineProperty(exports, "__esModule", { value: true }); /* * Copyright 2025, Salesforce, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ const core_1 = require("@actions/core"); const github_1 = require("@actions/github"); async function run() { try { // The issue request exists on payload when an issue is created // Sets action status to failed when issue does not exist on payload. const issue = github_1.context.payload.issue; if (!issue) { (0, core_1.setFailed)("github.context.payload.issue does not exist"); return; } // Get input parameters. const token = (0, core_1.getInput)("repo-token"); const message = (0, core_1.getInput)("message"); const label = (0, core_1.getInput)("label"); console.log("message: ", message); console.log("label: ", label); // Create a GitHub client. const octokit = (0, github_1.getOctokit)(token); // Get owner and repo from context const owner = github_1.context.repo.owner; const repo = github_1.context.repo.repo; // Create a comment on Issue // https://octokit.github.io/rest.js/#octokit-routes-issues-create-comment console.log("owner: " + owner); console.log("repo: " + repo); console.log("issue number: " + issue.number); const issueLabels = issue.labels; console.log("issue labels: ", issueLabels); // If label is passed in as an input, make sure it is on the issue before posting the message. // Otherwise, we want to post message on all issues regardless. if (label) { if (!issueLabels.find((issueLabel) => issueLabel.name === label)) { // We didn't find the label, so don't post on this issue. return; } } const { data: comments } = await octokit.rest.issues.listComments({ owner, repo, issue_number: issue.number, }); // If we have comments check out that this comment has not been previously commented if (comments.length) { if (comments.some((comment) => comment.body === message)) { console.log("Already commented"); return; } } const response = await octokit.rest.issues.createComment({ owner, repo, // eslint-disable-next-line @typescript-eslint/camelcase issue_number: issue.number, body: message, }); console.log("created comment URL: " + response.data.html_url); (0, core_1.setOutput)("comment-url", response.data.html_url); } catch (err) { const error = err; (0, core_1.setFailed)(error.message); } } run(); //# sourceMappingURL=index.js.map ================================================ FILE: .github/actions/new-issue/src/index.ts ================================================ /* * Copyright 2025, Salesforce, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ import { getInput, setOutput, setFailed } from "@actions/core"; import { context, getOctokit } from "@actions/github"; import { Label } from "@octokit/webhooks-definitions/schema"; async function run() { try { // The issue request exists on payload when an issue is created // Sets action status to failed when issue does not exist on payload. const issue = context.payload.issue; if (!issue) { setFailed("github.context.payload.issue does not exist"); return; } // Get input parameters. const token = getInput("repo-token"); const message = getInput("message"); const label = getInput("label"); console.log("message: ", message); console.log("label: ", label); // Create a GitHub client. const octokit = getOctokit(token); // Get owner and repo from context const owner = context.repo.owner; const repo = context.repo.repo; // Create a comment on Issue // https://octokit.github.io/rest.js/#octokit-routes-issues-create-comment console.log("owner: " + owner); console.log("repo: " + repo); console.log("issue number: " + issue.number); const issueLabels = issue.labels as Label[]; console.log("issue labels: ", issueLabels); // If label is passed in as an input, make sure it is on the issue before posting the message. // Otherwise, we want to post message on all issues regardless. if (label) { if (!issueLabels.find((issueLabel) => issueLabel.name === label)) { // We didn't find the label, so don't post on this issue. return; } } const { data: comments } = await octokit.rest.issues.listComments({ owner, repo, issue_number: issue.number, }); // If we have comments check out that this comment has not been previously commented if (comments.length) { if (comments.some((comment) => comment.body === message)) { console.log("Already commented"); return; } } const response = await octokit.rest.issues.createComment({ owner, repo, // eslint-disable-next-line @typescript-eslint/camelcase issue_number: issue.number, body: message, }); console.log("created comment URL: " + response.data.html_url); setOutput("comment-url", response.data.html_url); } catch (err) { const error = err as Error; setFailed(error.message); } } run(); ================================================ FILE: .github/actions/new-issue/tsconfig.json ================================================ { "extends": "@salesforce/dev-config/tsconfig-strict", "compilerOptions": { "outDir": "./lib" }, "files": ["src/index.ts"] } ================================================ FILE: .github/actions/validate-issue/action.yml ================================================ name: "Salesforce CLI Validate Issues" description: "Validate information provided in an new Github issue." author: "Eric Willhoit" inputs: repo-token: required: true description: "Token taken from secrets env var" runs: using: "node20" main: "lib/index.js" ================================================ FILE: .github/actions/validate-issue/lib/index.d.ts ================================================ export {}; ================================================ FILE: .github/actions/validate-issue/lib/index.js ================================================ "use strict"; /* * Copyright 2025, Salesforce, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ Object.defineProperty(exports, "__esModule", { value: true }); const core_1 = require("@actions/core"); const github_1 = require("@actions/github"); const child_process_1 = require("child_process"); const semver = require("semver"); const fs_1 = require("fs"); const path = require("path"); const nodeVersions_1 = require("./nodeVersions"); async function run() { try { // Uncomment for local testing // const issue = JSON.parse(getFile("../mock/sample-context.json")); const issue = github_1.context.payload.issue; if (!issue) { (0, core_1.setFailed)("github.context.payload.issue does not exist"); return; } // Temporary check to prevent this action from running on old issues // This will prevent noise on tickets already being investigated // This can be removed once the action has been running for a while const creationDate = new Date(issue.created_at); const cutoffDate = new Date("2023-06-14T00:00:00Z"); if (creationDate < cutoffDate) { console.log("Issue was created before 6/14/2023, skipping"); return; } // Create a GitHub client const token = (0, core_1.getInput)("repo-token"); const octokit = (0, github_1.getOctokit)(token); // Get owner and repo from context // uncomment env var for local testing // process.env.GITHUB_REPOSITORY = "iowillhoit/gha-sandbox"; const owner = github_1.context.repo.owner; const repo = github_1.context.repo.repo; const issue_number = issue.number; console.log("Issue URL:", issue.html_url); const { body } = issue; const { login: author } = issue.user; const { data: comments } = await getAllComments(); // For version checks, we only care about comments from the author const authorComments = comments.filter((comment) => { var _a; return ((_a = comment === null || comment === void 0 ? void 0 : comment.user) === null || _a === void 0 ? void 0 : _a.login) === author; }); // Build an array of the issue body and all of the comment bodies const bodies = [ body, ...authorComments.map((comment) => comment.body), ].filter((body) => body !== undefined); const sfVersionRegex = /@salesforce\/cli\/([0-9]+.[0-9]+.[0-9]+(-[a-zA-Z0-9]+.[0-9]+)?)/g; const sfdxVersionRegex = /sfdx-cli\/([0-9]+.[0-9]+.[0-9]+(-[a-zA-Z0-9]+.[0-9]+)?)/g; const pluginVersionsRegex = /pluginVersions|Plugin Version:/; const nodeVersionRegex = /node-v(\d{2})\.\d+\.\d+/g; // Search all bodies and get an array of all versions found (first capture group) const sfVersions = bodies .map((body) => [...body.matchAll(sfVersionRegex)].map((match) => match[1])) .flat(); const sfdxVersions = bodies .map((body) => [...body.matchAll(sfdxVersionRegex)].map((match) => match[1])) .flat(); const nodeVersions = bodies .map((body) => [...body.matchAll(nodeVersionRegex)].map((match) => match[1])) .flat(); // If we match pluginVersionRegex anywhere, we assume the user has provided the full --verbose output const pluginVersionsIncluded = bodies.some((body) => body === null || body === void 0 ? void 0 : body.match(pluginVersionsRegex)); console.log("sfVersions", sfVersions); console.log("sfdxVersions", sfdxVersions); console.log("pluginVersionsIncluded", pluginVersionsIncluded); console.log("nodeVersions", nodeVersions); if ((sfVersions.length > 0 || sfdxVersions.length > 0) && pluginVersionsIncluded) { // FUTURE TODO: // - Check for bundled plugins that are user installed (user) or linked (link) // - Could do a check to see if the users has a prerelease version installed let valid = true; if (sfVersions.length > 0) { const sfLatest = getLatestVersion("@salesforce/cli"); const oneSatisfies = sfVersions.some((version) => semver.gte(version, sfLatest)); if (!oneSatisfies) { if (sfVersions.find((v) => v.startsWith("2."))) { // If any sf versions provided start with 2.x, share update information const oldSf = getFile("../messages/old-cli.md", { THE_AUTHOR: author, USER_CLI: "sf", USER_VERSION: sfVersions.join("`, `"), LATEST_VERSION: sfLatest, }); postComment(oldSf); } else { // If not, share deprecation information const sfV1 = getFile("../messages/deprecated-cli.md", { THE_AUTHOR: author, OLD_CLI: "`sf` (v1)", }); postComment(sfV1); } valid = false; } } if (sfdxVersions.find((v) => v.startsWith("7.")) && !sfVersions.find((v) => v.startsWith("2."))) { const noOldSfdx = getFile("../messages/deprecated-cli.md", { THE_AUTHOR: author, OLD_CLI: "`sfdx` (v7)", }); postComment(noOldSfdx); valid = false; } if (nodeVersions.length > 0) { if (!(await (0, nodeVersions_1.isAnyVersionValid)(new Date())(nodeVersions))) { const nodeVersionMessage = getFile("../messages/unsupported-node.md", { THE_AUTHOR: author, NODE_VERSION: nodeVersions.join("`, `"), }); postComment(nodeVersionMessage); closeIssue(); valid = false; } } if (valid) { console.log("All information provided is valid!"); removeLabel("more information required"); addLabel("investigating"); // This label will prevent the action from running again after version info has been confirmed // Otherwise, this action will continue to trigger after every weekly release as `latest` is bumped addLabel("validated"); } else { console.log("Information provided is NOT valid"); addLabel("more information required"); removeLabel("investigating"); } } else { console.log("Full version information was not provided"); const message = getFile("../messages/provide-version.md", { THE_AUTHOR: issue.user.login, }); postComment(message); addLabel("more information required"); removeLabel("investigating"); } // --------- // FUNCTIONS // --------- async function closeIssue() { return await octokit.rest.issues.update({ owner, repo, issue_number, state: "closed", }); } async function getAllComments() { return await octokit.rest.issues.listComments({ owner, repo, issue_number, }); } async function postComment(body) { // Check that this comment has not been previously commented if (comments.length) { if (comments.some((comment) => comment.body === body)) { console.log("Already commented"); return; } } return await octokit.rest.issues.createComment({ owner, repo, issue_number, body, }); } async function addLabel(label) { await octokit.rest.issues.addLabels({ owner, repo, issue_number, labels: [label], }); } async function removeLabel(label) { try { await octokit.rest.issues.removeLabel({ owner, repo, issue_number, name: label, }); } catch (err) { const error = err; if (error.status === 404) { console.log(`Cannot remove label '${label}' since it was not applied`); return; } throw error; } } function getLatestVersion(plugin) { const distTags = (0, child_process_1.execSync)(`npm view ${plugin} dist-tags --json`).toString(); return JSON.parse(distTags).latest; } function getFile(filename, replacements) { let contents = (0, fs_1.readFileSync)(path.join(__dirname, filename), "utf8"); Object.entries(replacements || {}).map(([key, value]) => { contents = contents.replaceAll(key, value); }); return contents; } } catch (err) { const error = err; (0, core_1.setFailed)(error.message); } } run(); //# sourceMappingURL=index.js.map ================================================ FILE: .github/actions/validate-issue/lib/nodeVersions.d.ts ================================================ export declare const isAnyVersionValid: (currentDate: Date) => (versions: string[]) => Promise; ================================================ FILE: .github/actions/validate-issue/lib/nodeVersions.js ================================================ "use strict"; /* * Copyright 2025, Salesforce, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ Object.defineProperty(exports, "__esModule", { value: true }); exports.isAnyVersionValid = void 0; const isAnyVersionValid = (currentDate) => async (versions) => { const resp = (await (await fetch("https://raw.githubusercontent.com/nodejs/Release/main/schedule.json")).json()); return versions .map((version) => `v${version}`) .some((formattedVersion) => formattedVersion in resp && currentDate >= new Date(resp[formattedVersion].start) && currentDate <= new Date(resp[formattedVersion].end)); }; exports.isAnyVersionValid = isAnyVersionValid; //# sourceMappingURL=nodeVersions.js.map ================================================ FILE: .github/actions/validate-issue/messages/deprecated-cli.md ================================================ Hello @THE_AUTHOR :wave: It looks like you're using an outdated version of Salesforce CLI. OLD_CLI is in "maintenance mode" as of July 12, 2023. We highly recommend you move from OLD_CLI to `sf` (v2) ASAP. Moving to `sf` (v2) is easy and takes just two commands. Find all the information [here](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_move_to_sf_v2.htm). After you move to the latest version of `sf` (v2), run your command again and provide the output of `sf version --verbose --json`. ================================================ FILE: .github/actions/validate-issue/messages/old-cli.md ================================================ Hello @THE_AUTHOR :wave: None of the versions of `USER_CLI` you shared match the latest release. Shared: `USER_VERSION` Latest: `LATEST_VERSION` Update to the latest version of Salesforce CLI ([docs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_update_cli.htm)) and confirm that you're still seeing your issue. You can also try the `rc` and `nightly` releases! ([docs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_rc.htm)) After updating, share the full output of `USER_CLI version --verbose --json` ================================================ FILE: .github/actions/validate-issue/messages/provide-version.md ================================================ Hello @THE_AUTHOR :wave: It looks like you didn't include the full Salesforce CLI version information in your issue. Please provide the output of `version --verbose --json` for the CLI you're using (`sf` or `sfdx`). A few more things to check: - Make sure you've provided detailed steps to reproduce your issue. - A repository that clearly demonstrates the bug is ideal. - Make sure you've installed the latest version of Salesforce CLI. ([docs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_update_cli.htm)) - Better yet, try the `rc` or `nightly` versions. ([docs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_rc.htm)) - Try running the `doctor` command to diagnose common issues. - Search GitHub for existing related issues. Thank you! ================================================ FILE: .github/actions/validate-issue/messages/unsupported-node.md ================================================ Hello @THE_AUTHOR :wave: Your version of nodeJS (`NODE_VERSION`) is not supported. We recommend using LTS and we support anything Node says is `Current`, `Active` and `Maintenance`. See Node's [version status](https://nodejs.org/en/about/previous-releases). This issue will be closed. If you're able to reproduce your issue on a supported node version, please open a new issue. ================================================ FILE: .github/actions/validate-issue/mock/sample-context.json ================================================ { "active_lock_reason": null, "assignee": null, "assignees": [], "author_association": "OWNER", "body": "@salesforce/cli/1.60.5 sfdx-cli/7.204.6 darwin-arm64 node-v18.15.0 pluginVersions", "closed_at": null, "comments": 0, "comments_url": "https://api.github.com/repos/iowillhoit/gha-sandbox/issues/16/comments", "created_at": "2023-06-06T21:03:32Z", "events_url": "https://api.github.com/repos/iowillhoit/gha-sandbox/issues/16/events", "html_url": "https://github.com/iowillhoit/gha-sandbox/issues/16", "id": 1744609461, "labels": [ { "color": "FBCA04", "default": false, "description": "", "id": 5589614072, "name": "investigating", "node_id": "LA_kwDOI7bi188AAAABTSq9-A", "url": "https://api.github.com/repos/iowillhoit/gha-sandbox/labels/investigating" } ], "labels_url": "https://api.github.com/repos/iowillhoit/gha-sandbox/issues/16/labels{/name}", "locked": false, "milestone": null, "node_id": "I_kwDOI7bi185n_KC1", "number": 16, "performed_via_github_app": null, "reactions": { "+1": 0, "-1": 0, "confused": 0, "eyes": 0, "heart": 0, "hooray": 0, "laugh": 0, "rocket": 0, "total_count": 0, "url": "https://api.github.com/repos/iowillhoit/gha-sandbox/issues/16/reactions" }, "repository_url": "https://api.github.com/repos/iowillhoit/gha-sandbox", "state": "open", "state_reason": null, "timeline_url": "https://api.github.com/repos/iowillhoit/gha-sandbox/issues/16/timeline", "title": "Test", "updated_at": "2023-06-06T21:49:50Z", "url": "https://api.github.com/repos/iowillhoit/gha-sandbox/issues/16", "user": { "avatar_url": "https://avatars.githubusercontent.com/u/1715111?v=4", "events_url": "https://api.github.com/users/iowillhoit/events{/privacy}", "followers_url": "https://api.github.com/users/iowillhoit/followers", "following_url": "https://api.github.com/users/iowillhoit/following{/other_user}", "gists_url": "https://api.github.com/users/iowillhoit/gists{/gist_id}", "gravatar_id": "", "html_url": "https://github.com/iowillhoit", "id": 1715111, "login": "iowillhoit", "node_id": "MDQ6VXNlcjE3MTUxMTE=", "organizations_url": "https://api.github.com/users/iowillhoit/orgs", "received_events_url": "https://api.github.com/users/iowillhoit/received_events", "repos_url": "https://api.github.com/users/iowillhoit/repos", "site_admin": false, "starred_url": "https://api.github.com/users/iowillhoit/starred{/owner}{/repo}", "subscriptions_url": "https://api.github.com/users/iowillhoit/subscriptions", "type": "User", "url": "https://api.github.com/users/iowillhoit" } } ================================================ FILE: .github/actions/validate-issue/src/index.ts ================================================ /* * Copyright 2025, Salesforce, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ import { getInput, setFailed } from "@actions/core"; import { context, getOctokit } from "@actions/github"; import { execSync } from "child_process"; import * as semver from "semver"; import { readFileSync } from "fs"; import * as path from "path"; import { isAnyVersionValid } from "./nodeVersions"; async function run() { try { // Uncomment for local testing // const issue = JSON.parse(getFile("../mock/sample-context.json")); const issue = context.payload.issue; if (!issue) { setFailed("github.context.payload.issue does not exist"); return; } // Temporary check to prevent this action from running on old issues // This will prevent noise on tickets already being investigated // This can be removed once the action has been running for a while const creationDate = new Date(issue.created_at); const cutoffDate = new Date("2023-06-14T00:00:00Z"); if (creationDate < cutoffDate) { console.log("Issue was created before 6/14/2023, skipping"); return; } // Create a GitHub client const token = getInput("repo-token"); const octokit = getOctokit(token); // Get owner and repo from context // uncomment env var for local testing // process.env.GITHUB_REPOSITORY = "iowillhoit/gha-sandbox"; const owner = context.repo.owner; const repo = context.repo.repo; const issue_number = issue.number; console.log("Issue URL:", issue.html_url); const { body } = issue; const { login: author } = issue.user; const { data: comments } = await getAllComments(); // For version checks, we only care about comments from the author const authorComments = comments.filter( (comment) => comment?.user?.login === author ); // Build an array of the issue body and all of the comment bodies const bodies = [ body, ...authorComments.map((comment) => comment.body), ].filter((body): body is string => body !== undefined); const sfVersionRegex = /@salesforce\/cli\/([0-9]+.[0-9]+.[0-9]+(-[a-zA-Z0-9]+.[0-9]+)?)/g; const sfdxVersionRegex = /sfdx-cli\/([0-9]+.[0-9]+.[0-9]+(-[a-zA-Z0-9]+.[0-9]+)?)/g; const pluginVersionsRegex = /pluginVersions|Plugin Version:/; const nodeVersionRegex = /node-v(\d{2})\.\d+\.\d+/g; // Search all bodies and get an array of all versions found (first capture group) const sfVersions = bodies .map((body) => [...body.matchAll(sfVersionRegex)].map((match) => match[1]) ) .flat(); const sfdxVersions = bodies .map((body) => [...body.matchAll(sfdxVersionRegex)].map((match) => match[1]) ) .flat(); const nodeVersions = bodies .map((body) => [...body.matchAll(nodeVersionRegex)].map((match) => match[1]) ) .flat(); // If we match pluginVersionRegex anywhere, we assume the user has provided the full --verbose output const pluginVersionsIncluded = bodies.some((body) => body?.match(pluginVersionsRegex) ); console.log("sfVersions", sfVersions); console.log("sfdxVersions", sfdxVersions); console.log("pluginVersionsIncluded", pluginVersionsIncluded); console.log("nodeVersions", nodeVersions); if ( (sfVersions.length > 0 || sfdxVersions.length > 0) && pluginVersionsIncluded ) { // FUTURE TODO: // - Check for bundled plugins that are user installed (user) or linked (link) // - Could do a check to see if the users has a prerelease version installed let valid = true; if (sfVersions.length > 0) { const sfLatest = getLatestVersion("@salesforce/cli"); const oneSatisfies = sfVersions.some((version) => semver.gte(version, sfLatest) ); if (!oneSatisfies) { if (sfVersions.find((v) => v.startsWith("2."))) { // If any sf versions provided start with 2.x, share update information const oldSf = getFile("../messages/old-cli.md", { THE_AUTHOR: author, USER_CLI: "sf", USER_VERSION: sfVersions.join("`, `"), LATEST_VERSION: sfLatest, }); postComment(oldSf); } else { // If not, share deprecation information const sfV1 = getFile("../messages/deprecated-cli.md", { THE_AUTHOR: author, OLD_CLI: "`sf` (v1)", }); postComment(sfV1); } valid = false; } } if ( sfdxVersions.find((v) => v.startsWith("7.")) && !sfVersions.find((v) => v.startsWith("2.")) ) { const noOldSfdx = getFile("../messages/deprecated-cli.md", { THE_AUTHOR: author, OLD_CLI: "`sfdx` (v7)", }); postComment(noOldSfdx); valid = false; } if (nodeVersions.length > 0) { if (!(await isAnyVersionValid(new Date())(nodeVersions))) { const nodeVersionMessage = getFile( "../messages/unsupported-node.md", { THE_AUTHOR: author, NODE_VERSION: nodeVersions.join("`, `"), } ); postComment(nodeVersionMessage); closeIssue(); valid = false; } } if (valid) { console.log("All information provided is valid!"); removeLabel("more information required"); addLabel("investigating"); // This label will prevent the action from running again after version info has been confirmed // Otherwise, this action will continue to trigger after every weekly release as `latest` is bumped addLabel("validated"); } else { console.log("Information provided is NOT valid"); addLabel("more information required"); removeLabel("investigating"); } } else { console.log("Full version information was not provided"); const message = getFile("../messages/provide-version.md", { THE_AUTHOR: issue.user.login, }); postComment(message); addLabel("more information required"); removeLabel("investigating"); } // --------- // FUNCTIONS // --------- async function closeIssue() { return await octokit.rest.issues.update({ owner, repo, issue_number, state: "closed", }); } async function getAllComments() { return await octokit.rest.issues.listComments({ owner, repo, issue_number, }); } async function postComment(body: string) { // Check that this comment has not been previously commented if (comments.length) { if (comments.some((comment) => comment.body === body)) { console.log("Already commented"); return; } } return await octokit.rest.issues.createComment({ owner, repo, issue_number, body, }); } async function addLabel(label: string) { await octokit.rest.issues.addLabels({ owner, repo, issue_number, labels: [label], }); } async function removeLabel(label: string) { try { await octokit.rest.issues.removeLabel({ owner, repo, issue_number, name: label, }); } catch (err) { const error = err as Error & { status: number }; if (error.status === 404) { console.log( `Cannot remove label '${label}' since it was not applied` ); return; } throw error; } } function getLatestVersion(plugin: string) { const distTags = execSync( `npm view ${plugin} dist-tags --json` ).toString(); return JSON.parse(distTags).latest; } function getFile( filename: string, replacements: { [key: string]: string } | undefined ) { let contents = readFileSync(path.join(__dirname, filename), "utf8"); Object.entries(replacements || {}).map(([key, value]) => { contents = contents.replaceAll(key, value); }); return contents; } } catch (err) { const error = err as Error; setFailed(error.message); } } run(); ================================================ FILE: .github/actions/validate-issue/src/nodeVersions.ts ================================================ /* * Copyright 2025, Salesforce, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ type VersionInfo = { start: Date; end: Date; }; export const isAnyVersionValid = (currentDate: Date) => async ( versions: string[] ): Promise => { const resp = (await (( await fetch( "https://raw.githubusercontent.com/nodejs/Release/main/schedule.json" ) ).json() as unknown)) as Record; return versions .map((version) => `v${version}`) .some( (formattedVersion) => formattedVersion in resp && currentDate >= new Date(resp[formattedVersion].start) && currentDate <= new Date(resp[formattedVersion].end) ); }; ================================================ FILE: .github/actions/validate-issue/tsconfig.json ================================================ { "extends": "@salesforce/dev-config/tsconfig-strict", "compilerOptions": { "outDir": "./lib", "lib": ["ES2021"] }, "files": ["src/index.ts"] } ================================================ FILE: .github/workflows/closeStaleIssues.yml ================================================ name: Close Stale Issues permissions: issues: write on: workflow_dispatch: schedule: - cron: '30 1 * * *' jobs: stale: runs-on: ubuntu-latest steps: - uses: actions/stale@v7 with: stale-issue-label: stale days-before-issue-stale: 7 stale-issue-message: 'This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.' operations-per-run: 100 exempt-issue-labels: announcement,bug,on hold,waiting for internal reply,feature any-of-labels: more information required ================================================ FILE: .github/workflows/issue-updated.yml ================================================ name: "validate-updated-issue" on: issues: types: [edited] issue_comment: types: [created, edited] jobs: validate-issue: # Has label: 'more information required' # Does NOT have labels: # - 'validated' # - 'investigating' # - 'feature' # - 'owned by another team' # - 'bug' if: contains(github.event.issue.labels.*.name, 'more information required') && !contains(github.event.issue.labels.*.name, 'validated') && !contains(github.event.issue.labels.*.name, 'investigating') && !contains(github.event.issue.labels.*.name, 'feature') && !contains(github.event.issue.labels.*.name, 'owned by another team') && !contains(github.event.issue.labels.*.name, 'bug') runs-on: ubuntu-latest steps: - uses: actions/checkout@v3.0.0 - uses: actions/setup-node@v4 with: node-version: lts/* - name: Install dependencies run: yarn install - name: Validate issue id: validate-issue uses: ./.github/actions/validate-issue with: repo-token: ${{ secrets.GITHUB_TOKEN}} ================================================ FILE: .github/workflows/new-label.yml ================================================ name: "new-label" on: # any labels added to an issue issues: types: [labeled] jobs: owned-by-other-team: if: ${{ github.event.label.name == 'owned by another team' && !contains(github.event.issue.labels.*.name, 'feature') }} runs-on: ubuntu-latest steps: - uses: actions/checkout@v3.0.0 - uses: actions/setup-node@v4 with: node-version: lts/* - name: Install dependencies run: yarn install - name: issue comment id: issue_comment uses: ./.github/actions/new-issue with: repo-token: ${{ secrets.GITHUB_TOKEN }} label: "owned by another team" message: > We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official [Salesforce customer support](https://help.salesforce.com/s/) ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on. - name: log action output run: echo ${{ steps.run_action.outputs.message }} new-issue: if: ${{ github.event.label.name == 'investigating' }} runs-on: ubuntu-latest steps: - uses: actions/checkout@v3.0.0 - uses: actions/setup-node@v4 with: node-version: lts/* - name: Install dependencies run: yarn install - name: issue comment id: issue_comment uses: ./.github/actions/new-issue with: repo-token: ${{ secrets.GITHUB_TOKEN }} label: "investigating" message: > Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support. - name: log action output run: echo ${{ steps.run_action.outputs.message }} validate-new-issue: if: ${{ github.event.label.name == 'investigating' }} runs-on: ubuntu-latest steps: - uses: actions/checkout@v3.0.0 - uses: actions/setup-node@v4 with: node-version: lts/* - name: Install dependencies run: yarn install - name: Validate issue id: validate-issue uses: ./.github/actions/validate-issue with: repo-token: ${{ secrets.GITHUB_TOKEN }} new-feature: if: ${{ github.event.label.name == 'feature' && !contains(github.event.issue.labels.*.name, 'owned by another team') }} runs-on: ubuntu-latest steps: - uses: actions/checkout@v3.0.0 - uses: actions/setup-node@v4 with: node-version: lts/* - name: Install dependencies run: yarn install - name: issue comment id: issue_comment uses: ./.github/actions/new-issue with: repo-token: ${{ secrets.GITHUB_TOKEN }} label: "feature" message: > Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments. - name: log action output run: echo ${{ steps.run_action.outputs.message }} new-feature-on-another-team: if: >- (github.event.label.name == 'feature' || github.event.label.name == 'owned by another team') && (contains(github.event.issue.labels.*.name, 'feature') && contains(github.event.issue.labels.*.name, 'owned by another team')) runs-on: ubuntu-latest steps: - uses: actions/checkout@v3.0.0 - uses: actions/setup-node@v4 with: node-version: lts/* - name: Install dependencies run: yarn install - name: issue comment id: issue_comment uses: ./.github/actions/new-issue with: repo-token: ${{ secrets.GITHUB_TOKEN }} message: > Thank you for filing this feature request. However, we've determined that the functionality you've requested must be completed by another team. Please submit your request to the [Salesforce IdeaExchange](https://trailblazer.salesforce.com/ideaSearch). Then post a link to the request in this issue so that others can upvote your idea. - name: log action output run: echo ${{ steps.run_action.outputs.message }} ================================================ FILE: .gitignore ================================================ # Dependency directory node_modules # Rest pulled from https://github.com/github/gitignore/blob/master/Node.gitignore # Logs logs *.log npm-debug.log* yarn-debug.log* yarn-error.log* # Diagnostic reports (https://nodejs.org/api/report.html) report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json # Runtime data pids *.pid *.seed *.pid.lock # Optional npm cache directory .npm # dotenv environment variables file .env .env.test # OS metadata .DS_Store Thumbs.db # Ignore built ts files __tests__/runner/* package-lock.json /.idea ================================================ FILE: CHANGELOG.md ================================================ Changelog can be found here: https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md ================================================ FILE: CODEOWNERS ================================================ # Technical writers will be added as reviewers on markdown changes. *.md @forcedotcom/cli-docs # Comment line immediately above ownership line is reserved for related other information. Please be careful while editing. #ECCN:Open Source #GUSINFO:Platform CLI,Platform CLI ================================================ FILE: CODE_OF_CONDUCT.md ================================================ # Salesforce Open Source Community Code of Conduct ## About the Code of Conduct Equality is a core value at Salesforce. We believe a diverse and inclusive community fosters innovation and creativity, and are committed to building a culture where everyone feels included. Salesforce open-source projects are committed to providing a friendly, safe, and welcoming environment for all, regardless of gender identity and expression, sexual orientation, disability, physical appearance, body size, ethnicity, nationality, race, age, religion, level of experience, education, socioeconomic status, or other similar personal characteristics. The goal of this code of conduct is to specify a baseline standard of behavior so that people with different social values and communication styles can work together effectively, productively, and respectfully in our open source community. It also establishes a mechanism for reporting issues and resolving conflicts. All questions and reports of abusive, harassing, or otherwise unacceptable behavior in a Salesforce open-source project may be reported by contacting the Salesforce Open Source Conduct Committee at ossconduct@salesforce.com. ## Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of gender identity and expression, sexual orientation, disability, physical appearance, body size, ethnicity, nationality, race, age, religion, level of experience, education, socioeconomic status, or other similar personal characteristics. ## Our Standards Examples of behavior that contributes to creating a positive environment include: * Using welcoming and inclusive language * Being respectful of differing viewpoints and experiences * Gracefully accepting constructive criticism * Focusing on what is best for the community * Showing empathy toward other community members Examples of unacceptable behavior by participants include: * The use of sexualized language or imagery and unwelcome sexual attention or advances * Personal attacks, insulting/derogatory comments, or trolling * Public or private harassment * Publishing, or threatening to publish, others' private information—such as a physical or electronic address—without explicit permission * Other conduct which could reasonably be considered inappropriate in a professional setting * Advocating for or encouraging any of the above behaviors ## Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. ## Scope This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project email address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Salesforce Open Source Conduct Committee at ossconduct@salesforce.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The committee is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership and the Salesforce Open Source Conduct Committee. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant][contributor-covenant-home], version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html. It includes adaptions and additions from [Go Community Code of Conduct][golang-coc], [CNCF Code of Conduct][cncf-coc], and [Microsoft Open Source Code of Conduct][microsoft-coc]. This Code of Conduct is licensed under the [Creative Commons Attribution 3.0 License][cc-by-3-us]. [contributor-covenant-home]: https://www.contributor-covenant.org (https://www.contributor-covenant.org/) [golang-coc]: https://golang.org/conduct [cncf-coc]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md [microsoft-coc]: https://opensource.microsoft.com/codeofconduct/ [cc-by-3-us]: https://creativecommons.org/licenses/by/3.0/us/ ================================================ FILE: CONTRIBUTING.md ================================================ # Contributing to the Salesforce CLI Welcome, and thank you for your interest in contributing to the Salesforce CLI! There are multiple ways you can contribute. Before you get started, please review our [Code of Conduct](CODE_OF_CONDUCT.md) to help us keep our OSS projects a safe and welcoming environment. ### Report an issue Did you find a bug? First, make sure the bug wasn't already reported by searching on the `issues` section: https://github.com/forcedotcom/cli/issues. If you cannot find a related issue, then open a new one and follow the bug template. Providing a minimal reproduction is highly encouraged as these help us to quickly identify the root cause of the issue. ### Security Please report any security issue to security@salesforce.com as soon as it is discovered. ### Pull requests We accept pull requests for bug fixes and feature requests for any issues labeled with [`help wanted`](https://github.com/forcedotcom/cli/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22). You can leave a comment in the issue you are interested to work on and we will assign it to you. We work in branches off of `main`, to create a PR you should: 1. Fork the plugin/library repo you want to contribute to. 2. Create a new branch: `git checkout -b fix-bug` 3. Make your changes and ensure all tests pass. 4. [Create a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) #### Note: We use conventional commits in all of our repos. Our CI/CD pipeline relies on each commit type to decide whether or not to publish a new release and we enforce this using a git hook to run `commitlint`, make sure to folow this convention, otherwise `commitlint` will not allow you to commit your change. Conventional Commits: https://www.conventionalcommits.org/en/v1.0.0/#summary `commitlint`: https://github.com/conventional-changelog/commitlint/#what-is-commitlint ## CLA External contributors will be required to sign a Contributor's License Agreement. You can do so by going to: https://cla.salesforce.com/sign-cla. ## Building the project Prerequisites: * [Node.js](https://nodejs.org/) (recommended: latest active LTS release) * [Yarn v1](https://classic.yarnpkg.com/) (`npm install --global yarn`) 1. Clone the repo: * `sf`: `git clone https://github.com/salesforcecli/cli.git` 2. Install dependencies: `yarn install` 3. Build the project: `yarn build` 4. Run the CLI using the `bin/run` executable as: * macOS/linux: `bin/run` * Windows: `bin\run.cmd` ## Project structure The `sf` CLI is built from plugins, some are bundled and come installed with the CLI, others are installed on demand. The bundled plugins are: * [plugin-apex](https://github.com/salesforcecli/plugin-apex/) * [plugin-auth](https://github.com/salesforcecli/plugin-auth/) * [plugin-data](https://github.com/salesforcecli/plugin-data) * [deploy-retrieve](https://github.com/salesforcecli/plugin-deploy-retrieve) * [plugin-info](https://github.com/salesforcecli/plugin-info) * [plugin-limits](https://github.com/salesforcecli/plugin-limits) * [plugin-login](https://github.com/salesforcecli/plugin-login) * [plugin-org](https://github.com/salesforcecli/plugin-org) * [plugin-schema](https://github.com/salesforcecli/plugin-schema) * [plugin-settings](https://github.com/salesforcecli/plugin-settings) * [plugin-sobject](https://github.com/salesforcecli/plugin-sobject) * [plugin-telemetry](https://github.com/salesforcecli/plugin-telemetry) * [plugin-templates](https://github.com/salesforcecli/plugin-templates) * [plugin-trust](https://github.com/salesforcecli/plugin-trust) * [plugin-user](https://github.com/salesforcecli/plugin-user) The just-in-time plugins that are installed the first time you run a command are: * [plugin-custom-metadata](https://github.com/saleforcecli/plugin-custom-metadata) * [plugin-community](https://github.com/saleforcecli/plugin-community) * [plugin-dev](https://github.com/saleforcecli/plugin-dev) * [plugin-env](https://github.com/saleforcecli/plugin-env) * [plugin-functions](https://github.com/salesforcecli/plugin-functions) * [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) * [plugin-signups](https://github.com/saleforcecli/plugin-signups) * [sfdx-plugin-lwc-test](https://github.com/salesforcecli/sfdx-plugin-lwc-test) * [sfdx-scanner](https://github.com/salesforcecli/sfdx-scanner) For an up-to-date list of CLI plugins and libraries, see: https://github.com/salesforcecli/status ## Architecture For more information on how the `sf` CLI is organized, see https://github.com/salesforcecli/cli/blob/main/ARCHITECTURE.md ================================================ FILE: LICENSE.txt ================================================ Apache License Version 2.0 Copyright (c) 2025 Salesforce, Inc. All rights reserved. Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "{}" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright {yyyy} {name of copyright owner} Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ================================================ FILE: README.md ================================================ # Description This is an issue-only repository for Salesforce CLI. We monitor this repo for feedback from the community and we post proposals for CLI changes we're working on to see what you think. We also store the weekly release notes here. If you have a feature or enhancement request for Salesforce CLI, first review the [existing discussions](https://github.com/forcedotcom/cli/discussions) to see if someone has already requested it. If you don't see your feature or enhancement, click the **New discussion** button to create a new request. Similarly, if you've encountered a bug with Salesforce CLI, check out the [existing issues](https://github.com/forcedotcom/cli/issues) to see if it's already been reported. If you don’t see your bug listed, click the **New issue** button to create one. NOTICE: GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, use official Salesforce customer support channels. # Contributing If you are interested in contributing, take a look at the [CONTRIBUTING](.github/CONTRIBUTING.md) guide. When contributing to Github Actions, modify the `.github/actions/**/src` files. A pre-commit hook will build and commit the compiled `lib` files. When adding a new action, add the path to the `references` in the base `tsconfig.json` file. # A note on CLI Unification On July 2023 we [announced the General Availability (GA)](https://developer.salesforce.com/blogs/2023/07/salesforce-cli-sf-v2-is-here) of `sf` (v2), which is the culmination of our CLI unification efforts, which started back in 2021 with [`sf` (v1)](https://developer.salesforce.com/blogs/2021/06/announcing-salesforce-cli-unification). `sf` (v2) is smart enough to understand both `sfdx` and `sf` commands, and due to its smaller size, it's faster to install and update. For more information see: * [Move from `sfdx` (v7) to `sf` (v2)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_move_to_sf_v2.htm) * [Migrate `sfdx`-Style Commands to the New `sf`-Style](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_migrate.htm) # Salesforce DX and CLI Documentation * _[Release Notes](./releasenotes/README.md)_ - Read about the new and changed features in recent weekly updates to Salesforce CLI. * _[Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm)_ - How to install, update, and configure Salesforce CLI. * _[Salesforce DX Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm)_ - Step-by-step guide on how to use the Salesforce DX tools. * _[Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm)_ - Complete reference documentation for all Salesforce CLI commands. * _[sf Plugin Developer Guide](https://github.com/salesforcecli/cli/wiki/Quick-Introduction-to-Developing-sf-Plugins)_ - Learn how to create your own custom plugin. * [Build Apps Together with Package Development](https://trailhead.salesforce.com/en/content/learn/trails/sfdx_get_started) - Step-by-step Trailhead trail of tutorials for the Salesforce DX tools. * [Salesforce Developers Blog](https://developer.salesforce.com/blogs/) # The up-to-date list of CLI [Repositories](https://github.com/salesforcecli/status) ================================================ FILE: SECURITY.md ================================================ ## Security Please report any security issue to [security@salesforce.com](mailto:security@salesforce.com) as soon as it is discovered. This library limits its runtime dependencies in order to reduce the total cost of ownership as much as can be, but all consumers should remain vigilant and have their security stakeholders review all third-party products (3PP) like this one and their dependencies. ================================================ FILE: package.json ================================================ { "name": "cli", "version": "1.0.0", "description": "Issues Only repository for the community to submit feedback, raise issues and propose enhancements to the Salesforce CLI.", "scripts": { "build": "tsc --build" }, "husky": { "hooks": { "pre-commit": "yarn build && git add .github/actions/**/lib" } }, "repository": { "type": "git", "url": "git+https://github.com/forcedotcom/cli.git" }, "author": "Lisa Morgan", "dependencies": { "@actions/core": "^1.10.0", "@actions/github": "^5.1.1", "semver": "^7.5.2" }, "devDependencies": { "@octokit/webhooks-definitions": "^3.67.3", "@salesforce/dev-config": "^2.0.0", "@types/node": "^20.11.17", "@types/semver": "^7.5.0", "husky": "^4.3.0", "prettier": "^1.19.1", "typescript": "4.9.5" }, "bugs": { "url": "https://github.com/forcedotcom/cli/issues" }, "homepage": "https://github.com/forcedotcom/cli#readme", "license": "Apache-2.0" } ================================================ FILE: releasenotes/README.md ================================================ # Salesforce CLI Release Notes Here are the new and changed features in recent updates of Salesforce CLI. We publish a new stable version of Salesforce CLI on Wednesdays. At the same time we also publish a release candidate that contains changes that will likely be in next week's stable release. We also publish nightly releases every night. Run `sf version` to display the version installed on your computer. > **IMPORTANT**: Are you still using `sfdx` (v7)? If so, we recommend that you move to `sf` (v2). It's easy: simply uninstall `sfdx` and then install `sf`. See the new [Move from `sfdx` (v7) to `sf` (v2)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_move_to_sf_v2.htm) section of the Setup Guide for details, including how to update your continuous integration (CI) scripts. We've also updated the entire Setup Guide to assume you're using `sf` (v2) and the `sf`-style CLI commands and configuration. **`sfdx` (v7) will receive no updates.** If you installed Salesforce CLI using the installers or TAR files, run `sf update stable` to update to the latest available stable version. Run `sf update stable-rc` to update to this week's release candidate and `sf update nightly` to update to the most recent nightly. If you installed Salesforce CLI using `npm`, run `npm install @salesforce/cli@latest --global` to install the latest stable version. Run `npm install @salesforce/cli@latest-rc --global` to install the release candidate and `npm install @salesforce/cli@nightly --global` to install the recent nightly. For all installation methods, see [this document](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli_olderversions) to install an old Salesforce CLI release. If you use [autocomplete](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_autocomplete.htm), run `sf autocomplete --refresh-cache` after you update Salesforce CLI to ensure that autocomplete works correctly on any new commands. Report and read about issues [here](https://github.com/forcedotcom/cli/issues). Join the discussion about new features we're considering [here](https://github.com/forcedotcom/cli/discussions). Looking for the release notes for previous Salesforce CLI releases? See [`sfdx` (v7)](./sfdx/README.md) and [`sf` (v1)](./sf/README.md). Additional documentation: * [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm) * [Salesforce DX Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm) * [Salesforce CLI Plugin Developer Guide](https://github.com/salesforcecli/cli/wiki/Quick-Introduction-to-Developing-sf-Plugins) * [Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm) ## 2.130.8 (April 8, 2026) [stable-rc] These changes are in the Salesforce CLI release candidate. We plan to include these changes in next week's official release. This list isn't final and is subject to change. ------------ * NEW: We standardized the error codes that `agent` commands throw when they run into issues. For example, both `agent publish authoring-bundle` and `agent validate authoring-bundle` now throw the same error code if they run into Agent Script compilation errors. These are the error codes that the `agent` commands might throw: |Error Code| Error Text| |--------|------- |`Succeeded (0)`|Preview session ended successfully and traces saved.| |`NotFound (2)`|Agent not found, or no preview session exists for this agent.| |`PreviewEndFailed (4)`|Failed to end the preview session.| |`SessionAmbiguous (5)`|Multiple preview sessions found; specify --session-id to choose one.| (plugin-agent PR [#378](https://github.com/salesforcecli/plugin-agent/pull/378)) * CHANGE: When running `agent preview start` to start a programmatic agent preview session using an agent's authoring bundle (`--authoring-bundle` flag), you're now required to specify either simulated or live mode. Specify simulated mode with the new `--simulate-actions` flag; specify live actions with the existing `--use-live-actions` flag. Previously, the programmatic agent preview ran in simulated mode by default; to use live mode you had to explicitly specify the `--use-live-actions` flag. Published agents, which you specify with the --api-name, always use live actions. (plugin-agent PR [#380](https://github.com/salesforcecli/plugin-agent/pull/380)) * FIX: If the `org assign permset` CLI command encounters multiple errors during a permission set assignment, we now correctly provide all the known details about the errors in the JSON output so you can better diagnose the problem. (GitHub Issue [#3511](https://github.com/forcedotcom/cli/issues/3511), plugin-user PR [#1398](https://github.com/salesforcecli/plugin-user/pull/1398)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * CnfgItemSourceDefinition (replaces CnfgMgmtCiSourceDef) * ExtlClntAppOauthSecuritySettings * UIBundle (replaces WebApplication) ## 2.129.8 (April 1, 2026) [stable] * NEW: Create a Salesforce DX project that includes a sample agent with the new `agent` template value of the `template generate project` command. For example: ```bash sf template generate project --name my-agent-project --template agent ``` The new `agent` template is also listed as an option when you create a project in VS Code with the **SFDX: Create Project** command. The generated Salesforce DX project contains a sample agent called `Local Info Agent` inside the `force-app/main/default/aiAuthoringBundles/Local_Info_Agent` authoring bundle. The agent could be embedded in a resort's web site to provide local weather updates, share information about local events, and help guests with facility hours. The agent demonstrates: - Three types of subagents (Invocable Apex, Prompt Template, and Flow). - Mutable variables. - Flow control with `available when`. - Deterministic branching with `if/else` in reasoning instructions. The DX project also includes other metadata that implement the sample agent, such as Apex classes, a flow, and a prompt template, as well as permission sets and permission set groups. See the `README.md` file in the root directory of the new DX project for more info. (salesforcedx-templates PR [#753](https://github.com/forcedotcom/salesforcedx-templates/pull/753), plugin-templates PR [#874](https://github.com/salesforcecli/plugin-templates/pull/874)) * NEW: (Generally Available) The commands to preview an agent programmatically, without starting an interactive session, are now generally available. These commands are particularly useful when you want an agent to test your agent. - `agent preview start`: Start a programmatic agent preview session. - `agent preview send`: Send a message to an existing agent preview session. - `agent preview sessions`: List all known programmatic agent preview sessions. - `agent preview end`: End an existing programmatic agent preview session and get trace location. (plugin-agent PR [#367](https://github.com/salesforcecli/plugin-agent/pull/367)) * NEW: We added the [Agentforce DX VS Code Extension](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-agents) to this week's release of the Salesforce Extension Pack (v66.3), which is available from either the [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode) or the [Open VSX Registry](https://open-vsx.org/extension/salesforce/salesforcedx-vscode). This change means that if you're setting up Agentforce DX tools for the first time on VS Code, you only need to install the Salesforce extension pack, which includes all the things. Already set up your tools? Then you don't need to do anything. The Salesforce Extension Pack includes tools for developing on the Salesforce Platform. Use these tools to work with development orgs (scratch orgs, sandboxes, and Developer Edition orgs), Apex, Lightning web components, and SOQL. The extension pack also includes Agentforce Vibes, and now Agentforce DX. (salesforcedx-vscode PR [#7003](https://github.com/forcedotcom/salesforcedx-vscode/pull/7003)) * NEW: Easily create the default Salesforce user that is used to run an agent in your org with the new `org create agent-user` CLI command. You specify this user in the agent's Agent Script file using the `default_agent_user` parameter in the [`config` block](https://developer.salesforce.com/docs/ai/agentforce/guide/ascript-blocks.html#config-block). By default, the command generates a user called `Agent User` with a globally unique username. Use the `--first-name`, `--last-name`, and `--base-username` flags to change these default names. The command also assigns the required profiles and permission sets. Run `sf org create agent-user --help` for more details. When the command completes, it displays a summary of what it did, including the new agent user's username and ID. This example creates an agent user with an auto-generated username but the custom name `Service Agent` in the org with alias `my-org`: ```bash sf org create agent-user --first-name Service --last-name Agent --target-org my-org ``` (vscode-agents PR [#168](https://github.com/forcedotcom/vscode-agents/pull/168)) * NEW: When you activate an agent in VS Code with the **AFDX: Active Agent** command, you're now prompted for the version you want to activate. (vscode-agents PR [#168](https://github.com/forcedotcom/vscode-agents/pull/168)) * NEW: Specify a custom directory into which the `agent generate template` command generates the `BotTemplate` and `GenAiPlannerBundle` files with the new `--output-dir` flag. If you don't specify this flag, then the files are generated in the default package directory. This example generates an agent template of version 1 of the `My_Awesome_Agent` Bot metadata file into the `my-package` directory: ```bash sf agent generate template --agent-file force-app/main/default/bots/My_Awesome_Agent/My_Awesome_Agent.bot-meta.xml --agent-version 1 --source-org my-scratch-org --output-dir my-package ``` (plugin-agent PR [#376](https://github.com/salesforcecli/plugin-agent/pull/376)) * NEW: (oclif only) Use the new `multiple: true` support of positional arg definitions to give your commands a type-safe way to accept a variable number of positional arguments. See [Command Arguments](https://oclif.io/docs/args) for more info. Thank you, [Espen Hovlandsdal](https://github.com/rexxars), for your contribution to oclif! While Salesforce CLI avoids the usage of positional arguments and varargs, other non-Salesforce developers who build CLIs on oclif are sure to find this new feature useful. (core PR [#1554](https://github.com/oclif/core/pull/1554)) * CHANGE: For increased security, we changed the behavior of `org generate password` so it always generates passwords of higher complexity. Specifically, if you pass the `--complexity` flag a value below 3, the command now ignores that value and instead generates a password of complexity 3, which means a password that includes only lower and upper case letters and numbers. The command also displays a message about this changed behavior. Starting in Summer '26, the command will fail if you specify a complexity value less than 3. (plugin-user PR [#1389](https://github.com/salesforcecli/plugin-user/pull/1389), * FIX: We fixed [this issue](https://help.salesforce.com/s/issue?id=a02Ka00000ji2nu) with the `agent generate template` command caused by packaging local actions and topics. As a result of the fix, you can now correctly generate an agent template, and then package the template in a second-generation managed package, without going through the workaround. IMPORTANT: This fix added a new requirement when you run `agent generate template`: you must now use the new `--source-org` flag to specify the username or alias of the namespaced scratch org that contains the agent which the template is based on. For example, this command generates an agent template from version 1 of the `My_Awesome_Agent` Bot metadata file in your DX project; the agent that the new template is based on is in the org with alias "my-scratch-org": ```bash sf agent generate template --agent-file force-app/main/default/bots/My_Awesome_Agent/My_Awesome_Agent.bot-meta.xml --agent-version 1 --source-org my-scratch-org ``` (plugin-agent PR [#376](https://github.com/salesforcecli/plugin-agent/pull/376)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * CnfgItemAttrDef * CnfgItemAttrPcklstValDef * CnfgItemAttrPicklistDef * CnfgItemAttrSetAttr * CnfgItemAttrSetDef * CnfgItemTypeAttrRelDef * CnfgItemTypeDef * CnfgItemTypeRelationDef * CnfgMgmtRelationTypeDef * CnfgMgmtCiSourceDef * MeetingPlaybookDefinition * TelemetryDefinition * TelemetryDefinitionVersion * TelemetryActionDefinition * TelemetryActionDefStep * TelemetryActnDefStepAttr ## 2.128.5 (March 25, 2026) * NEW: The Lightning Local Dev CLI commands are now just-in-time (JIT). This means that when you update to this Salesforce CLI release and run a `lightning dev` command, Salesforce CLI checks if the associated [plugin-lightning-dev](https://github.com/salesforcecli/plugin-lightning-dev) is installed. If it's not, Salesforce CLI automatically installs it and then runs your command. These are the CLI commands included in this plugin: * `lightning dev app` : Preview a Lightning Experience app locally and in real-time, without deploying it. │ * `lightning dev component` : Preview LWC components in isolation. │ * `lightning dev site` : Preview an Experience Builder site locally and in real-time, without deploying it. See [Preview Components with Local Dev](https://developer.salesforce.com/docs/platform/lwc/guide/get-started-test-components.html) for information about using the commands. These new commands will also soon be included in the [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_unified.htm). * NEW: Specify the version of an agent you want to activate with the new `--version` flag of `agent activate`. If you run the command without the `--version` flag, the command provides a list of agent versions for you to choose from. The value of `--version` is always a number, corresponding to the `vX` part of the `BotVersion` metadata in your project. For example, if you have a `force-app/main/default/bots/My_Agent/v4.botVersion-meta.xml` file in your project, then you activate this agent version in an org with alias `my-org` like this: ```bash sf agent activate --api-name My_Agent --version 4 --target-org my-org ``` You can now also specify JSON output for the `agent activate` and `agent deactivate` commands with the new `--json` flag. (plugin-agent PR [#348](https://github.com/salesforcecli/plugin-agent/pull/348)) * CHANGE: For enhanced security, the minimum (and new default) value of the `--length` flag of the `org generate password` CLI command is now 20. If you specify a value less than 20, the command displays a message and uses 20 instead. Starting in Summer '26, the command will fail if you specify a password length less than 20. The maximum value is still 100. (plugin-user PR [#1372](https://github.com/salesforcecli/plugin-user/pull/1372)) * FIX: The `project retrieve start` command now correctly retrieves specific versions of the `Bot` metadata type (`BotVersion`); previously it would retrieve just the latest version. This example shows how to retrieve version 3 of the Local_Info_Agent `Bot`: ```bash sf project retrieve start --metadata Bot:Local_Info_Agent --metadata BotVersion:Local_Info_Agent.v3 ``` (source-deploy-retrieve PR [#1706](https://github.com/forcedotcom/source-deploy-retrieve/pull/1706)) * FIX: The `project deploy start` command now works correctly when you use both mechanisms for deleting metadata components at the same time: use a destructive change file (such as `--pre-destructive-changes manifest/destructiveChangesPre.xml`) and remove a different component from the standard manifest file (such as `--manifest manifest/package.xml`). (source-deploy-retrieve PR [#1690](https://github.com/forcedotcom/source-deploy-retrieve/pull/1690), plugin-deploy-retrieve PR [#1508](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1508)) ## 2.127.2 (March 18, 2026) * FIX: The `data bulk export` CLI command now works correctly even when exporting many records (such as 700K+). (GitHub Issue [#3507](https://github.com/forcedotcom/cli/issues/3507), plugin-data PR [#1388](https://github.com/salesforcecli/plugin-data/pull/1388)) * FIX: You can now successfully retrieve individual `BotVersion` metadata components, such as `sf project retrieve start --metadata BotVersion:MyAgent.v1`. (GitHub Issue [#3516](https://github.com/forcedotcom/cli/issues/3516), source-deploy-retrieve PR [#1704](https://github.com/forcedotcom/source-deploy-retrieve/pull/1704)) * FIX: You can now correctly deploy and retrieve `SchedulingObjective` metadata components. (GitHub Issue [#3514](https://github.com/forcedotcom/cli/issues/3514), source-deploy-retrieve PR [#1700](https://github.com/forcedotcom/source-deploy-retrieve/pull/1700)) * FIX: Using `--flags-dir` to [read flag values from a file](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_flag_values_in_files.htm) now correctly works with commands in non-core third-party plugins. (GitHub Issue [#3493](https://github.com/forcedotcom/cli/issues/3493), oclif core PR [#1553](https://github.com/oclif/core/pull/1553), oclif plugin-plugins PR [#1288](https://github.com/oclif/plugin-plugins/pull/1288)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * MktDatalakeSrcKeyQualifier * ProcedurePlanDefinition ## 2.126.4 (March 11, 2026) * NEW: The `dev generate flag` command now supports generating flags for commands that use the `src/commands/hello/world/index.ts` file layout in the plugin repo, in addition to `src/commands/hello/world.ts`. The command now also tries to find an existing messages file for adding the new flag's help text. Many thanks to [AndrewLPetersonSF](https://github.com/AndrewLPetersonSF) for contributing this useful feature! (plugin-dev PR #533) * CHANGE: If you specify the `--json` flag for an interactive Agentforce DX command, but not a required flag, the command now correctly stops executing and displays an error. In this context, "interactive" refers to a command that prompts you for values if you don't explicitly specify a required flag. For example, the `--name` flag is required for `agent generate authoring-bundle`. * If you run `sf agent generate authoring-bundle`, then you're prompted for the name of the authoring bundle. * If you run `sf agent generate authoring-bundle --json`, then the command returns an error because in this case you must specify `--name`. (plugin-agent PR [#336](https://github.com/salesforcecli/plugin-agent/pull/336)) * FIX: We fixed an issue in how Salesforce CLI recognizes the shell that it's being run from. (oclif GitHub Issue [#1538](https://github.com/oclif/core/issues/1538), oclif core PR [#1548](https://github.com/oclif/core/pull/1548)) ## 2.125.1 (March 4, 2026) * NEW: When generating an authoring bundle with the `agent generate authoring-bundle` Agentforce DX command, use the `--force-overwrite` flag to overwrite the existing authoring bundle if one with the same API name already exists locally. For example: ```bash sf agent generate authoring-bundle --no-spec --api-name My_Authoring_Bundle --force-overwrite ``` (plugin-agent PR [#327](https://github.com/salesforcecli/plugin-agent/pull/327)) ## 2.124.7 (Feb 25, 2026) * NEW: Generate an Experience Cloud site in your DX project with the new `template generate digital-experience site` command. After you pass the command the name of a template (currently only `BuildYourOwnLWR`), the new site name, and an URL path prefix, all the required metadata files are created locally. The metadata files correspond to metadata components such as DigitalExperienceConfig, DigitalExperienceBundle, Network, and CustomSite. The `BuildYourOwnLWR` template creates super-fast digital experiences, such as websites, microsites, and portals, using the Lightning Web Components programming model. Powered by Lightning Web Runtime (LWR), this customizable template delivers unparalleled site performance. For additional details, see this Salesforce Help topic: https://help.salesforce.com/s/articleView?id=experience.rss_build_your_own_lwr.htm. Here's an example that generates the metadata files in the `force-app/main/default` directory: ```bash sf template generate digital-experience site --template BuildYourOwnLWR --name mysite --url-path-prefix mysite --output-dir force-app/main/default ``` (plugin-templates PR [#829](https://github.com/salesforcecli/plugin-templates/pull/829)) * NEW: Generate a FlexiPage in your DX project with the new `template generate flexipage` command. FlexiPages are the metadata types associated with a Lightning page, which represents a customizable screen made up of regions containing Lightning components. You can generate these types of FlexiPages: `AppPage`, `HomePage`, or `RecordPage`. This example generates a `RecordPage` Flexipage for the Account object in the `force-app/main/default/flexipages` directory: ```bash sf template generate flexipage --name Account_Record_Page --template RecordPage --sobject Account --output-dir force-app/main/default/flexipages ``` (plugin-templates PR [#833](https://github.com/salesforcecli/plugin-templates/pull/833)) * CHANGE: We reorganized all the commands in [plugin-templates](https://github.com/salesforcecli/plugin-templates) under a top-level topic called `template generate`. As a result, you can now take advantage of autocomplete to list all the available templates to generate things, such as DX projects or Apex classes. But don't worry, we also added aliases to the moved commands, so that the old command names will still work. But they display a deprecation warning that the command name has changed. Here are all the affected commands. (plugin-templates PR [#840](https://github.com/salesforcecli/plugin-templates/pull/840), plugin-templates PR [#838](https://github.com/salesforcecli/plugin-templates/pull/838)) | Old command | New command | | ----------- | ----------- | | apex generate class | template generate apex class | | apex generate trigger | template generate apex trigger | | analytics generate template | template generate analytics template | | lightning generate app | template generate lightning app | | lightning generate component | template generate lightning component | | lightning generate event | template generate lightning event | | lightning generate interface | template generate lightning interface | | lightning generate test | template generate lightning test | | project generate | template generate project | | static-resource generate | template generate static-resource | | visualforce generate component | template generate visualforce component | | visualforce generate page | template generate visualforce page | * FIX: Salesforce CLI now properly shuts down node processes after sending telemetry events. (GitHub Issues [#3505](https://github.com/forcedotcom/cli/issues/3505) and [#3506](https://github.com/forcedotcom/cli/issues/3506), plugin-telemetry PR [#835](https://github.com/salesforcecli/plugin-telemetry/pull/835)) ## 2.123.1 (Feb 18, 2026) * NEW: **(Generally Available) Build Enterprise-Ready Agents with Agentforce DX and Agent Script** After a successful [beta](./README.md#211515-dec-10-2025), we're happy to announce the generally availability of Agentforce DX to build hybrid reasoning Salesforce agents that use Agent Script. These new types of agents have both the predictability that your business demands and the creativity that large language models (LLMs) make possible. Agentforce DX helps pro-code developers build these agents by minimizing context switching, enabling professional DevOps, and simplifying collaboration between low-code and pro-code developers. For the list of features we announced in the beta, see [these release notes](https://help.salesforce.com/s/articleView?id=release-notes.rn_tools_afdx_nga_beta.htm&release=260&type=5). Since the beta announcement, we've added or improved the following features: - **Agentforce Vibes Rules for Agent Script**: Agentforce Vibes now includes a global rule for coding Agent Script files. - **Improved Agent Preview**: Previewing an agent now works the same regardless of how you started the conversation (using an Agent Script file or a published agent.) Previously you had to configure additional security using a connected app to preview a published agent. - **Programmatic Agent Preview**: (Beta) Preview an agent programmatically, without starting an interactive session, with these four new CLI commands; this feature is particularly useful when you want an agent to test your agent. - `agent preview start`: Start a programmatic agent preview session. - `agent preview send`: Send a message to an existing agent preview session. - `agent preview sessions`: List all known programmatic agent preview sessions. - `agent preview end`: End an existing programmatic agent preview session and get trace location. - **Enhanced Session Tracer**: Get oodles of useful session trace information with the enhanced Agent Tracer panel in VS Code. - **Simpler Authoring Bundle Generation**: You're no longer required to generate an agent spec YAML file when generating an authoring bundle. This feature makes it even easier to get started with Agent Script agents. The version of the Agentforce DX for VS Code Extension that contains these GA features is 1.7.0; install it from either the [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-agents) or [Open VSX Registry](https://open-vsx.org/extension/salesforce/salesforcedx-vscode-agents). See the [Build Agents with Agentforce DX](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-dx.html) section of the _Agentforce Developer Guide_ for details. * NEW: Generate a package ZIP file that you can use for debugging or to examine the package contents when you run `package version create` with the new `--generate-pkg-zip` flag. This example creates a package version from the contents of the `common` directory and gives it an installation key of `password123` and generates a package ZIP file: ``` $ sf package version create --path common --installation-key password123 --generate-pkg-zip --target-dev-hub my-dev-hub ``` (plugin-packaging PR [#1117](https://github.com/salesforcecli/plugin-packaging/pull/1117)) * FIX: Retrieving DigitalExperienceBundle metadata components now works correctly after you update the Digital Experience site in the org. Specifically, let's say you created a page in the Digital Experience site using the in-org builder, and then retrieved it to your DX project with the `project retrieve start` CLI command. You then change the mobile layout in the org, and retrieve the metadata again. Before this fix, the `mobile.json` file was incorrectly created at the top-level of the page; now it's correctly nested in `mobile/mobile.json`. (source-deploy-retrieve PR [#1680](https://github.com/forcedotcom/source-deploy-retrieve/pull/1680)) * FIX: CLI commands that don't require an org no longer run really slowly in directories in which the `target-org` config variable points to a long-expired scratch org. (GitHub Issue [#3425](https://github.com/forcedotcom/cli/issues/3425), jsforce PR [#1772](https://github.com/jsforce/jsforce/pull/1772)) ## 2.122.6 (Feb 11, 2026) * NEW: Skip retrieving new or changed metadata from your org when you publish an agent's authoring bundle with the new `--skip-retrieve` flag of `agent publish authoring-bundle`. This feature is useful when you publish the authoring bundle in a CI job and don't need to retrieve the metadata back to your DX project because it already has it; skipping the retrieve can save time. This example shows how to publish an authoring bundle with API name `MyAuthoringBundle` to the org with alias `my-dev-org`, but not retrieve any of the metadata: ```bash sf agent publish authoring-bundle --api-name MyAuthoringbundle --skip-retrieve --target-org my-dev-org ``` (plugin-agent PR [#304](https://github.com/salesforcecli/plugin-agent/pull/304), agents PR [#204](https://github.com/forcedotcom/agents/pull/204)) * FIX: When you specify flag values in files via the `--flags-dir` flag, overriding the flags at the command-line now works correctly for all types of flags. Previously, the command would fail if you overrode a flag using its long flag name when it also has a short name. Thank you, [Jon Freed](https://github.com/jon-freed), for your contribution. This is your second one in two weeks, you're now quite the expert on `--flags-dir`. Do you have a third one coming up? Ha, no pressure! But seriously, we love your contribution, thanks again. (GitHub Issue [#3486](https://github.com/forcedotcom/cli/issues/3486), cli PR [#2554](https://github.com/salesforcecli/cli/pull/2554)) * FIX: The `project deploy start` command now correctly handles an empty `deploy-cache.json` file (an internal file that the CLI uses to manage deployments) rather than throwing a confusing error. (GitHub Issue [#3387](https://github.com/forcedotcom/cli/issues/3387), sfdx-core PR [#1260](https://github.com/forcedotcom/sfdx-core/pull/1260)) ## 2.121.7 (Feb 4, 2026) * NEW: Open your org right in Agentforce Studio, specifically in the list view that displays all your agents, with the new `org open authoring-bundle` command. This example opens Agentforce Studio in an org with alias `my-org`; the command opens the browser in incognito mode: ```bash sf org open authoring-bundle --private --target-org my-org ``` * CHANGE: Previewing a published agent with the `agent preview` CLI command no longer requires the extra security of a specially-configured connected app. Rather, use the standard way to authorize the org in which the published agent is active (such as with the `org loging web` command) and then you can immediately use `agent preview` to chat with it. As a result of this change, we've removed the `--client-app` flag from `agent preview` because it's no longer needed. When you run the `agent preview` command without arguments, the list of published agents you can chat with are prepended with the label `(Published)`. Agents labeled `(Agent Script)` are local to your DX project and the `agent preview` command uses their local Agent Script file in your DX project to preview it. * CHANGE: Over the next few weeks we're ending support for these two operating system-specific installers and TAR files: * Windows x86 * Linux ARM We are removing the download button for the [Windows x86](https://developer.salesforce.com/tools/salesforcecli) installer from the download page (the Linux ARM TAR file was already removed). We'll keep some [old versions](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli_olderversions) for a while, but they too will become unavailable in the future. * FIX: Salesforce DX projects now support the WebApplication [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.120.3 (Jan 27, 2026) * NEW: Improve the usability and maintainability of the [configuration files that contain flag values](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_flag_values_in_files.htm) by adding comments that begin with either `#` or `//`. For example, let's say that the file `flags/sobject` in your DX project contains the value of the `--sobject` flag of `data create record`. You can comment the file like this: ```bash # Create a record in the Account object Account ``` Thank you, [Jon Freed](https://github.com/jon-freed), for contributing the code for this excellent new feature. It definitely makes the "flags-dir" feature easier to use and maintain. We love it! (This new feature actually released back in November 2025, so apologies for the tardy announcement.) (cli PR [#2399](https://github.com/salesforcecli/cli/pull/2399)) * FIX: We improved the performance of the `project retrieve start` command. In particular, retrieves of large metatdata components, such as massive static resources, now finish correctly rather than hanging indefinitely. (sfdx-core PR [#1256](https://github.com/forcedotcom/sfdx-core/pull/1256), jsforce PR [#1784](https://github.com/jsforce/jsforce/pull/1784)) * FIX: The `package version` commands now work correctly when specifying `--api-version 60.0` (or lower); previously, some commands returned the `ErrorInvalidIdNoMatchingVersionIdError` error. (GitHub Issue [#3481](https://github.com/forcedotcom/cli/issues/3481), packaging PR [#796](https://github.com/forcedotcom/packaging/pull/796), plugin-packaging PR [#1108](https://github.com/salesforcecli/plugin-packaging/pull/1108)) * FIX: If you create a second sys admin user in a scratch org, and then authorize the scratch org using that second username, then the `org list` command now correctly lists that org with the second username. (GitHub Issue [#3439](https://github.com/forcedotcom/cli/issues/3439), plugin-org PR [#1551](https://github.com/salesforcecli/plugin-org/pull/1551)) * FIX: Logging out of multiple orgs with the `org logout --all` command, and deselecting the ones you want to stay logged into, is now working correctly. (GitHub Issue [#3296](https://github.com/forcedotcom/cli/issues/3296), plugin-auth PR [#1437](https://github.com/salesforcecli/plugin-auth/pull/1437), sfdx-core PR [#1255](https://github.com/forcedotcom/sfdx-core/pull/1255)) ## 2.119.8 (Jan 20, 2026) * CHANGE: We removed the `org login device` command from Salesforce CLI, as announced on [August 27, 2025](./README.md#21037-aug-27-2025). We removed the command because it uses the the OAuth 2.0 device flow, which is being blocked by Salesforce. For details see [Prepare for Connected App Usage Restrictions Change](https://help.salesforce.com/s/articleView?id=005132365&type=1&utm_source=techcomms&utm_medium=email&utm_campaign=FY26_Core_4013001). Use one of these commands instead of `org login device`: * [`org login jwt`](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm) to authorize an org in headless environments, such as CI. * [`org login web`](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm) to authorize an org using a browser. * FIX: We fixed a bug that caused deploys and retrieves to hang indefinitely during certain connection errors. (source-deploy-retrieve PR [#1663](https://github.com/forcedotcom/source-deploy-retrieve/pull/1663)) * FIX: Users who have the Manage Dev Sandboxes user permission can now successfully run the `org refresh sandbox` command. (plugin-org PR [#1569](https://github.com/salesforcecli/plugin-org/pull/1569)) * FIX: We fixed all known issues when using Node.js v25 with Salesforce CLI. We still officially support v24, which is the [Active LTS version of Node.js](https://nodejs.org/en/about/previous-releases). * FIX: When creating a sandbox with the `org create sandbox` command, you can now list the features in the sandbox definition file as either an array (`"features": ["SandboxStorage"]`) or a string (`"features": "['SandboxStorage']"`). (GitHub Issue [#3479](https://github.com/forcedotcom/cli/issues/3479), sfdx-core PR [#1254](https://github.com/forcedotcom/sfdx-core/pull/1254)) * FIX: Salesforce DX projects now support the FlexcardDefinition [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.118.20 (Jan 14, 2026) * FIX: We fixed some under-the-hood bugs. ## 2.117.7 (Jan 7, 2026) * NEW: The debug log information outputted by the `--dev-debug` flag now includes the list of files that were ignored during a deployment or retrieval. This information is useful to debug your `.forceignore` file and understand exactly what's being ignored when you run `project deploy|retrieve start`. (GitHub Issue [#3345](https://github.com/forcedotcom/cli/issues/3345), source-deploy-retrieve PR [#1656](https://github.com/forcedotcom/source-deploy-retrieve/pull/1656)) * UPDATE: Use the existing `package update` command to set the recommended version of a package. When you set a package version as the recommended version, your subscribers see an **Upgrade to Recommended Version** option on the Installed Packages page in their org. Only released package versions can be set as the recommended version. This example sets `PackageA@1.0 as` the recommended version. ```bash sf package update --package 0Ho.. --target-dev-hub devhub@example.com --recommended-version-id PackageA@1.0 ``` Run `package update --help` for more information. NOTE: This feature is available for only Spring '26 orgs (API version 66.0). * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * IntegArtifactDef * OnboardingDataObjectGroup * PartyProfileDataObjectValidityDefinition ## December 23 and 30, 2025 Due to the holiday break in the United States, we aren't releasing new stable versions. Happy holidays! ## 2.116.6 (Dec 17, 2025) * NEW: Specify the number of seconds to poll the org to check for the test status when you run `apex test run` with the new `--poll-interval`. Previously the poll interval was hard-coded to 1 second. This example shows how to set the poll interval to 5 seconds: ```bash sf apex run test --class-names MyClassTest --result-format human --poll-interval 5 --target-org my-org ``` (GitHub Issue [#3456](https://github.com/forcedotcom/cli/issues/3456), plugin-apex PR [#832](https://github.com/salesforcecli/plugin-apex/pull/832), salesforcedx-apex PR [#597](https://github.com/forcedotcom/salesforcedx-apex/pull/597)) * FIX: If an org is configured to block API connections, running one of the `org login` CLI commands now fails quickly rather than going into a loop until, for example, maximum login requests are reached. (GitHub Issue [#3428](https://github.com/forcedotcom/cli/issues/3428), sfdx-core PR [#1248](https://github.com/forcedotcom/sfdx-core/pull/1248), jsforce PR [#1774](https://github.com/jsforce/jsforce/pull/1774)) * FIX: Salesforce DX projects now support the `StageAssignment` [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.115.15 (Dec 10, 2025) * NEW: (Beta) Build complex, deterministic, enterprise-ready agents with Agent Script and Agentforce DX. Agentforce DX is the pro-code equivalent of the newly-released [Agentforce Builder](https://help.salesforce.com/s/articleView?id=release-notes.rn_einstein_agent_builder.htm&release=258&type=5) UI that runs in your org. See [Author an Agent with Agentforce DX](https://developer.salesforce.com/docs/einstein/genai/guide/agent-dx-nga-author-agent.html) in the _Agentforce Developer Guide_ for more information. New features include: * Author agents using [Agent Script](https://developer.salesforce.com/docs/einstein/genai/guide/agent-script.html), the language for building Salesforce agents. Agent Script combines the flexibility of using natural language for code generation with the reliability of programmatic expressions for handling business rules. * Easily edit Agent Script files in the VS Code editor with the new [Agent Script VS Code extension](https://marketplace.visualstudio.com/items?itemName=salesforce.agent-script-language-client), which provides standard code editing features: syntax highlighting, visual syntax cues (such as red squiggles for errors), internal validation, and Outline support. * Preview an agent conversation from its Agent Script file and get the behind-the-scenes details of how your agent is working with the updated [Agentforce DX VS Code Extension](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-agents) The preview supports two modes: simulated (which mocks data) and live mode (which uses real Apex classes, flows, and other resources). * Generate, validate, and publish an _authoring bundle_ with these new CLI commands. An authoring bundle is a new metadata type ([AiAuthoringBundle](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_aiauthoringbundle.htm)) that represents an agent that uses Agent Script as its blueprint. * `agent generate authoring-bundle`: Generate an authoring bundle from an existing agent spec YAML file. * `agent validate authoring-bundle`: Validate an authoring bundle to ensure its Agent Script file compiles successfully and can be used to publish an agent. * `agent publish authoring-bundle`: Publish an authoring bundle to your org, which results in a new agent or a new version of an existing agent. * FIX: You no longer get an error if you run `apex run test` asynchronously, such as with the `--wait 0` flag, and also specify an output format or `--code-coverage`. (GitHub Issue [#2963](https://github.com/forcedotcom/cli/issues/2963), salesforcedx-apex PR [#596](https://github.com/forcedotcom/salesforcedx-apex/pull/596)) * FIX: The `org login web` command, when run with the `--scopes` flag, now correctly requests the specified authentication (OAuth) scopes, rather than always requesting the default scopes (`refresh_token api web`). (plugin-auth PRs [#1420](https://github.com/salesforcecli/plugin-auth/pull/1420) and [#1423](https://github.com/salesforcecli/plugin-auth/pull/1423)) ## 2.114.5 (Dec 3, 2025) * NEW: (Beta) Specify that you want to run only relevant Apex tests when you deploy metadata to your org with the new `RunRelevantTests` value of the `--test-level` flag of the `project deploy start|validate` and `project delete source` commands. Salesforce automatically identifies the relevant tests based on an analysis of the deployment payload and the payload dependencies. For fine-grained control, you can also annotate test classes so that they always run in certain conditions. See [@IsTest Annotation](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_isTest.htm) in the _Apex Developer Guide_. Each class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code coverage. This coverage is computed for each class and triggers individually and is different than the overall coverage percentage. **NOTE**: This feature is available only for Spring '26 orgs (API version 66.0). This example deploys source files in the `force-app` package directory to the org with alias `my-scratch` and runs only the Apex tests that are relevant to the actual metadata that's being deployed: ```bash sf project deploy start --source-dir force-app --test-level RunRelevantTests --target-org my-scratch ``` (plugin-deploy-retrieve PR [#1479](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1479), source-deploy-retrieve PR [#1644](https://github.com/forcedotcom/source-deploy-retrieve/pull/1644)) * FIX: The `project retrieve start` command now correctly fails and outputs an error message if you specify an output directory (with the `--output-dir` flag) that is outside of the Salesforce DX project. (GitHub Issue [#3432](https://github.com/forcedotcom/cli/issues/3432), plugin-deploy-retrieve PR [#1480](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1480)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * AccountPlanObjMeasCalcDef (GitHub Issue [#3395](https://github.com/forcedotcom/cli/issues/3395)) * LightningOutApp (GitHub Issue [#3435](https://github.com/forcedotcom/cli/issues/3435)) * DataObjectSearchIndexConf (GitHub Issue [#3441](https://github.com/forcedotcom/cli/issues/3441)) ## Nov 26, 2025 Due to the Thanksgiving break in the United States, we aren't releasing a new stable version. Happy Thanksgiving! ## 2.113.6 (Nov 19, 2025) * FIX: We fixed some under-the-hood bugs. ## 2.112.6 (Nov 12, 2025) **ANNOUNCEMENT OF UPCOMING CHANGES** * **`plugins link` Command**: (This change impacts Salesforce CLI plugin developers who use `yarn` as their package manager.) Starting March 2026, the `plugins link` command will no longer automatically install dependencies after it links the specified plugin into Salesforce CLI. You will need to run `yarn` manually to install the required dependencies before you run `plugins link`. In this release, the `plugins link` command has been updated to include a reminder about this upcoming change. This change doesn't impact plugin developers who use `npm` or `pnmp` as their package manager because those types of plugins already don't get dependencies automatically installed when linked. (oclif plugin-plugins PR [#1230](https://github.com/oclif/plugin-plugins/pull/1230)) * **Bundled Node.js Version**: Starting February 2026, the Salesforce CLI installer for Windows, macOS, and Linux tarballs will start bundling Node.js v24 (Current LTS) instead of Node.js v22 (Maintenance LTS). See [this pinned GitHub issue](https://github.com/forcedotcom/cli/issues/3445) for additional information. ## 2.111.7 (Nov 5, 2025) * NEW: Retrieve package metadata for a specified package version with the new `package version retrieve` command. Package metadata can be retrieved for only second-generation managed package versions or unlocked packages. This example shows how to retrieve package metadata for a converted subscriber package version ID (starts with 04t) into `my-directory/` within your Salesforce DX project directory: ```bash sf package version retrieve --package 04tXXX --output-dir my-directory/ --target-dev-hub devhub@example.com ``` * FIX: Salesforce DX projects now support the FlowValueMap [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.110.22 (Oct 29, 2025) * FIX: Using the `SF_MDAPI_TEMP_DIR` environment variable when running `project retrieve start` now generates a correct directory name on Windows. (GitHub Issue [#3416](https://github.com/forcedotcom/cli/issues/3416), plugin-deploy-retrieve PR [#1460](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1460), source-deploy-retrieve PR [#1635](https://github.com/forcedotcom/source-deploy-retrieve/pull/1635)) * FIX: The `org open` and `org open agent` commands now correctly generate frontdoor URLs so you can now successfully use the `--source-file` flag to open the org at a specific builder, such as or Agentforce Builder or the setup page for Apex classes. (GitHub Discussion [#3427](https://github.com/forcedotcom/cli/discussions/3427), plugin-org PR [#1529](https://github.com/salesforcecli/plugin-org/pull/1529)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * ComputeExtension * DataMapperDefinition * GiftEntryGridTemplate * IntegrationProcdDefinition * McpServerDefinition * OmniscriptDefinition ## 2.109.7 (Oct 22, 2025) * NEW: If you authorize an org with the `org login web` CLI command, but it runs into an issue during the org login process, the CLI command now times out after 2 minutes rather than hang indefinitely. You can customize the number of milliseconds that the command waits to timeout with the new SF_WEB_OAUTH_SERVER_TIMEOUT environment variable. The default value is 120000 (2 minutes). This example sets the timeout to 3 minutes: ```bash export SF_WEB_OAUTH_SERVER_TIMEOUT=180000 ``` (sfdx-core PR [#1245](https://github.com/forcedotcom/sfdx-core/pull/1245), sfdx-core PR [#1246](https://github.com/forcedotcom/sfdx-core/pull/1246)) ## Oct 8 and 15, 2025 Due to Dreamforce, we aren't releasing a new stable version on these dates. If you're attending Dreamforce, stop by Moscone West and say hello! ## 2.108.6 (Oct 1, 2025) * FIX: Salesforce DX projects now support the TransactionProcessingType [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.107.6 (Sept 24, 2025) * NEW: (Beta) Run tests for multiple Salesforce features, such as Apex classes and Flows, in a single and unified way with these new commands: - `logic run test`: Invoke tests for Apex and Flows in an org. - `logic get test`: Get the results of a test run if it timed out. Running the tests together with a single command ensures seamless interoperability between the features. Many flags of these new commands mimic the flags for the existing `apex run|get test` and `flow run|get test` commands, such as `--tests`, `--test-level`, `--code-coverage`, `--class-names`, `--output-dir`, and more. But the new `logic run test` command expands the `--tests` flag so that you can specify _both_ Apex and Flow tests and adds a `--test-category` flag to narrow the type of tests you want to run. To specify a flow test, use this format: `FlowTesting.`. Run `sf logic run test --help` for more information about getting the exact name of a Flow test. By default, the `logic run test` command executes asynchronously and returns a test run ID. Then use the `logic get test` command to retrieve the results. If you want to wait for the test run to complete and see the results in the command output, use the `--synchronous` flag. This example runs all local Apex and Flow tests in the org with alias `my-scratch` asynchronously: ```bash sf logic run test --test-level RunLocalTests --test-category Apex --test-category Flow --target-org my-scratch ``` The command returns a test run ID which you pass to the `logic get test` command to get the test results: ```bash sf logic get test --test-run-id ``` (plugin-apex PR [#792](https://github.com/salesforcecli/plugin-apex/pull/792) and [#795](https://github.com/salesforcecli/plugin-apex/pull/795)) * CHANGE: As we noted in the [April 30, 2025](README.md#2869-april-30-2025) release notes, Salesforce CLI now returns an error when you run `org logout` on an org that you haven't authorized; since April the command displayed only a warning. The exit code in this scenario has also changed from 0 to 1. (GitHub Issue [#3247](https://github.com/forcedotcom/cli/issues/3247), plugin-auth PR [#1366](https://github.com/salesforcecli/plugin-auth/pull/1366)) * FIX: We fixed a regression in the `apex run test` command so that it now makes the expected number of API calls. (GitHub Issue [#3380](https://github.com/forcedotcom/cli/issues/3380), salesforcedx-apex PR [#569](https://github.com/forcedotcom/salesforcedx-apex/pull/569)) * FIX: We increased the request timeout period in the JSForce `node-fetch` wrapper to prevent Salesforce CLI commands (such as `org create scratch`) from timing out too quickly. (GitHub Issue [#3354](https://github.com/forcedotcom/cli/issues/3354), jsforce PRs [#1738](https://github.com/jsforce/jsforce/pull/1738) and [#1745](https://github.com/jsforce/jsforce/pull/1745)) * FIX: We fixed the Salesforce CLI telemetry dependencies and now the CLI is using all the correct licenses. (GitHub Issue [#3392](https://github.com/forcedotcom/cli/issues/3392), telemetry PR [#450](https://github.com/forcedotcom/telemetry/pull/450)) * FIX: We updated `apex run test` to align with the changed API response in v65.0, which in turned fixed the TypeError in `apex get test`. (GitHub Issue [#3389](https://github.com/forcedotcom/cli/issues/3389), salesforcedx-apex PR [#568](https://github.com/forcedotcom/salesforcedx-apex/pull/568)) ## 2.106.6 (Sept 17, 2025) * FIX: We fixed a Windows security vulnerability to ensure that the Salesforce CLI installer always executes the correct `cmd.exe` file. (cli PR [#2365](https://github.com/salesforcecli/cli/pull/2365), oclif PR [#1852](https://github.com/oclif/oclif/pull/1852)) ## 2.105.6 (Sept 10, 2025) * ANNOUNCEMENTS: * Starting 8/28/2025, the OAuth 2.0 Device Flow is blocked in the default `Salesforce CLI` connected app. See the [pinned issue](https://github.com/forcedotcom/cli/issues/3368) for more information. * Starting in December 2025, the `project deploy start` and `project retrieve start` commands will require that the target org use source tracking, unless you specify the metadata you want to deploy or retrieve. If you deploy or retrieve to an org that doesn’t use source tracking, then you must specify the metadata you want to deploy or retrieve. See the [pinned issue](https://github.com/forcedotcom/cli/issues/3375) for more information. ------------ * FIX: We fixed some under-the-hood bugs. ## 2.104.6 (Sept 3, 2025) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * FieldMappingConfig * FieldMappingConfigItem ## 2.103.7 (Aug 27, 2025) * NEW: Check out the new release of the [Agentforce DX for VS Code extension](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-agents)! You can now chat with an active agent using the new Agent Preview panel to see how the agent responds to your statements, questions, and commands (utterances). This feature is the VS Code equivalent of the `agent preview` CLI command. And if an agent action that's implemented with an Apex class encounters an error, you can use **Debug Mode** during the chat to automatically invoke the [Apex Replay Debugger](https://developer.salesforce.com/docs/platform/sfvscode-extensions/guide/replay-debugger.html). See the [README](https://github.com/forcedotcom/vscode-agents/blob/HEAD/README.md#preview-an-agent-and-debug-the-conversation) for prerequisites and instructions for using this feature. * NEW and CHANGED: Last week (in version 2.102.6), we introduced a new feature to display details about an invoked action when running agent tests with the `agent test run|resume|report` CLI commands. These details are in JSON format and displayed in the Generated Data section of the test results. Depending on the action, the JSON can get pretty long. So for simplicity, we no longer output these details _by default_; instead, use the new `--verbose` flag to output the details. This example runs an agent test and specifies that the output should include the generated data: ```bash sf agent test run --api-name Resort_Manager_Test --verbose --wait 40 ``` (plugin-agent PR [#189](https://github.com/salesforcecli/plugin-agent/pull/189)) * CHANGE: We removed the `--async` flag of each of these commands: * `data delete bulk` * `data export bulk` * `data import bulk` * `data update bulk` * `data upsert bulk` The commands don't need the `--async` flag because they're asynchronous by default. We deprecated the flag back in [April 23, 2025)](./README.md#2857-april-23-2025. (plugin-data PR [#1303](https://github.com/salesforcecli/plugin-data/pull/1303)) * CHANGE: We deprecated the `org login device` command and will remove it from Salesforce CLI in the near future. It's also now hidden, so it won't appear when you run `sf org login -h`. We are taking these actions because the command uses the the OAuth 2.0 device flow, which is being blocked. For details see [Prepare for Connected App Usage Restrictions Change](https://help.salesforce.com/s/articleView?id=005132365&type=1&utm_source=techcomms&utm_medium=email&utm_campaign=FY26_Core_4013001). We recommend that instead of `org login device`, you use one of these other commands: * [`org login jwt`](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm) to authorize an org in headless environments, such as CI. * [`org login web`](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm) to authorize an org using a browser. * FIX: Salesforce DX projects now support the UiPreviewMessageTabDef [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.102.6 (Aug 20, 2025) * NEW: Easily activate or deactivate an agent in your org when using the [VS Code Agentforce DX extension](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-agents) by right-clicking on one of the agent's Bot metadata files and clicking **SFDX: Activate Agent** or **SFDX: Deactivate Agent**. The agent's Bot metadata files are in the `bots` folder of your package directory (`force-app` by default). Activating an agent makes it immediately available to your users. If you deactivate a currently-active agent, which makes it unavailable to users, you're prompted to confirm. Only one agent version can be active at a time, so if you activate a new version, the old one is deactivated. If you (de)activate an agent from its Bot folder or its main Bot metadata file (such as `Resort_Manager.bot-meta.xml`), the latest agent version is (de)activated. To (de)activate a non-latest version, right-click on its version file, such as `v1.botVersion-meta.xml`. (vscode-agents PR [#55](https://github.com/forcedotcom/vscode-agents/pull/55)) * NEW: When running agent tests with the `agent test run|resume|report` CLI commands or from the VS Code Agent Testing Panel, and a test utterance invoked an action, the test results now include details about the invoked action in JSON format. Details include any Apex classes or Flows that were invoked, any Salesforce objects that were touched, and so on. (plugin-agent PR [#185](https://github.com/salesforcecli/plugin-agent/pull/185)) * CHANGE: As we announced in [March 2025](https://github.com/forcedotcom/cli/issues/3249), when you now use the `org open` command with the `--json` or `--url-only` flags, the generated URLs in the output will be single-use only. This means that the URLs can be used only one time; subsequent use won’t allow you to log into the org. The URLs also expire 60 seconds after they are generated. Finally, as a result of this change, we no longer support the `SF_SINGLE_USE_ORG_OPEN_URL` environment variable. (plugin-org PR [#1484](https://github.com/salesforcecli/plugin-org/pull/1484)) * FIX: The CatalogedApiArtifactVerInfo metadata type has been correctly renamed CatalogedApiArtifactVersionInfo in the [metadata registry](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). (source-deploy-retrieve PR [#1600](https://github.com/forcedotcom/source-deploy-retrieve/pull/1600)) ## 2.101.5 (Aug 13, 2025) * NEW: Easily activate or deactivate an agent in your org with the new `agent activate|deactivate` commands. Activating an agent makes it immediately available to your users. The two commands use the agent's API name; if you know it, use the `--api-name` flag to specify it. If you don't use the flag, the command lists the agents in your org for you to select. This example shows how to activate an agent with API name `Coral_Cloud_Agent` in your default org: ```bash sf agent activate --api-name Coral_Cloud_Agent ``` This example prompts you to choose an agent to deactivate in the org with alias `my-org`: ```bash sf agent deactivate --target-org my-org ``` (plugin-agent PR [#182](https://github.com/salesforcecli/plugin-agent/pull/182)) * NEW: Add more context to agent tests with the updated `agent generate test-spec` CLI command which now asks if you want to add boilerplate conversation history to each individual test case. The boilerplate is simply a template that you then edit with the specific history of a conversation that can happen before the test case's utterance. For example, let's say you're testing a shopping assistant agent, and a test case has the utterance of "When will my purchase arrive?". To better test this utterance, you can add a conversation history like this: ```yaml conversationHistory: - role: user message: I purchased an item last week but it hasn't arrived yet. - role: agent message: What is your order ID? topic: ask_for_order_id - role: user message: It's 123456. - role: agent message: You ordered a Wacky Cat Bobblehead, right? Great choice. topic: look_up_order ``` The `agent generate test-spec` command uses the Agentforce Testing API under the covers. For more information, see [Conversation History](https://developer.salesforce.com/docs/einstein/genai/guide/testing-api-build-tests.html#conversation-history). (plugin-agent PR [#181](https://github.com/salesforcecli/plugin-agent/pull/181)) * NEW: Display the dependency graph for an unlocked or 2GP managed package version with the new `package version displaydependencies` CLI command. This example displays the dependencies of the specified package version in the order that the dependencies must be installed (root last): ```bash sf package version displaydependencies --package 04t... --edge-direction root-last --target-dev-hub devhub@example.com ``` Run `sf package version displaydependencies` for additional examples and configuration information. (plugin-packaging PR [#1018](https://github.com/salesforcecli/plugin-packaging/pull/1018)) * CHANGE: We removed the `@salesforce/sfdx-scanner` plugin from the list of JIT (just in time) plugins. As a result, you must manually install the plugin if you want to use a `scanner` command and the plugin isn't installed in Salesforce CLI. We removed this plugin from the JIT list because it contains CLI commands for Code Analyzer v4, which being [retired](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/release-notes.md#code-analyzer-v4120-end-of-life). Use [Code Analyzer v5](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html) instead. (cli PR [#2322](https://github.com/salesforcecli/cli/pull/2322)) ## 2.100.4 (Aug 6, 2025) * NEW: Add custom evaluations to your agent test spec with the updated `agent generate test-spec` command, which now asks if you want to add one to a specific test case. Custom evaluations test an agent response for specific strings or numbers. If you opt to add a custom evaluation to an agent test case, you'll be prompted for the following information: * Label: A descriptive name of the custom evaluation. * JSONPath expression: Enables you to automatically point to the data you want to test. For details on how to construct a JSONPath expression, see [Dynamically Reference Generated Data](https://developer.salesforce.com/docs/einstein/genai/guide/testing-api-custom-evaluation-criteria.html#dynamically-reference-generated-data). * Comparison operator: The operator used to compare the expected and actual values returned from the test. Examples are equals, greater than or equal, and so on. * Expected value: The value you expect after the evaluation is tested. The `agent generate test-spec` command uses the Agentforce Testing API under the covers. Therefore, for more information, see [Add Custom Evaluation Criteria to a Test Case](https://developer.salesforce.com/docs/einstein/genai/guide/testing-api-custom-evaluation-criteria.html#get-started-with-custom-evaluation-criteria). (plugin-agent PR [#177](https://github.com/salesforcecli/plugin-agent/pull/177)) * FIX: You can once again successfully create a scratch org asynchronously (`org create scratch --async`) and then resume its creation (`org resume scratch`). (GitHub Issue [#3322](https://github.com/forcedotcom/cli/issues/3322), sfdx-core PR [#1207](https://github.com/forcedotcom/sfdx-core/pull/1207), plugin-org PR [#1473](https://github.com/salesforcecli/plugin-org/pull/1473)) * FIX: The `agent generate test-spec` command now works correctly with both the GenAiPlanner (legacy) and GenAiPlannerBundle (new) metadata types, both of which represent agent planners. (plugin-agent PR [#174](https://github.com/salesforcecli/plugin-agent/pull/174)) * FIX: We updated the npm dependencies in our project templates so that you no longer get an error when you run `project generate` and then `npm install` in the DX project. (GitHub Issue [#3222](https://github.com/forcedotcom/cli/issues/3222), GitHub Issue [#3278](https://github.com/forcedotcom/cli/issues/3278), GitHub Issue [#3295](https://github.com/forcedotcom/cli/issues/3295)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * CatalogedApi * CatalogedApiVersion * CatalogedApiArtfctVerInfo * RuleLibraryDefinition (GitHub Issue [#3099](https://github.com/forcedotcom/cli/issues/3099)) ## 2.99.6 (July 30, 2025) * NEW: We improved the performance of deploys and retrieves. (source-deploy-retrieve PR [#1583](https://github.com/forcedotcom/source-deploy-retrieve/pull/1583), source-deploy-retrieve PR [#1591](https://github.com/forcedotcom/source-deploy-retrieve/pull/1591)) Many thanks to Jon Freed ((@jon-freed)[https://github.com/jon-freed]), who is actually the "we" in the previous sentence. Jon contributed all the source code, which cleverly cuts back the number of string manipulations and simplifies key lookups, resulting in faster deployments and retrievals. We are delighted with your generous contribution. ## 2.98.6 (July 23, 2025) * NEW: We've improved the performance of `project deploy|retrieve start` when used with source tracking. (source-tracking PRs [#794](https://github.com/forcedotcom/source-tracking/pull/794) and [#732](https://github.com/forcedotcom/source-tracking/pull/732)) Big thanks to Luke Cotter ([@lukecotter](https://github.com/lukecotter)) who contributed all the code for this awesome performance improvement. Who doesn't love a faster metadata deployment? We really appreciate it, Luke! * FIX: You can now successfully deploy a new custom field and updated workflow to your org when using decomposed workflows (beta) in your DX project. (GitHub Issue [#3320](https://github.com/forcedotcom/cli/issues/3320)) * FIX: Salesforce DX projects now support the ExternalStoragePrvdConfig [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.97.6 (July 16, 2025) * FIX: Running `project deploy start` with the `--dry-run` flag is now working correctly. (GitHub Issue [#3336](https://github.com/forcedotcom/cli/issues/3336), plugin-deploy-retrieve PR [#1395](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1395)) ## 2.96.4 (July 9, 2025) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * ApiNamedQuery * ObjIntegProviderDefMapping * DataConnector * ExtlClntAppCanvasStngs ## 2.95.6 (July 3, 2025) * FIX: Salesforce CLI now displays tables correctly when column size is resolved to 0 in some CI environments. (GitHub issue [#3317](https://github.com/forcedotcom/cli/issues/3317), oclif PR [#167](https://github.com/oclif/table/pull/167) * FIX: You can now correctly clone a sandbox with Data Storage Upgrades. (GitHub issue [#3293](https://github.com/forcedotcom/cli/issues/3293), sfdx-core PR [#1205](https://github.com/forcedotcom/sfdx-core/pull/1205) * FIX: The `sf agent generate test-spec` command no longer generates a Yaml file with an empty expectedActions array when the action contains single quotes. (GH issue [#3314](https://github.com/forcedotcom/cli/issues/3314), Agents PR [#115](https://github.com/forcedotcom/agents/pull/115)) * FIX: We fixed a bug in which the string replacement functionality incorrectly emits warning saying the string to replace was not found when processing large files. (GH issue [#3318](https://github.com/forcedotcom/cli/issues/3318), source-deploy-retrieve PR [#1577](https://github.com/forcedotcom/source-deploy-retrieve/pull/1577)) ## 2.94.6 (June 25, 2025) * FIX: The `sf project deploy start` command no longers modifies source-tracking info when using the `--dry-run` flag. (GitHub issue [#3243](https://github.com/forcedotcom/cli/issues/3243), plugin-deploy-retrieve PR [#1372](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1372) * NEW: We’ve added a --code-coverage flag to the package convert command. Calculate and store the code coverage percentage by running the packaged Apex tests included in the package version. To promote a package version to released, you must use the --code-coverage flag. The package must also meet the code coverage requirements. This example converts the latest managed-released version of the 1GP package with the specified package ID and calculates code coverage; the example uses the default Dev Hub org: ```bash sf package convert --package 033... --code-coverage ``` ## 2.93.7 (June 18, 2025) * NEW: Link multiple connected apps in an org to an authenticated user, enabling Salesforce CLI commands to use these connected apps for API-specific requirements, like new OAuth scopes or JWT-based access tokens. As a result of this new feature, the authentication flow to use the `agent preview` CLI command to interact with an agent is now much easier. Previously you had to create a new Salesforce username for each Agentforce agent you wanted to interact with, and then specify it with the `--connected-app-user` flag. Now you use the same username you normally authenticate with, then specify the link to the connected app with the new `--client-app` flag. The `agent preview` command is currently the only CLI command that requires this feature. Let's see how this works. First, you create the link to a connected app by re-running the `org login web` command and using the `--client-id` flag to specify the connected app's consumer secret (also called _client id_). You also specify these new flags: * `--client-app`: The name of the link to the connected app. You can specify any string you want. * `--username`: The username of the authenticated user. This is the username you specified when you originally authorized your org with `org login web`. * `--scopes`: The OAuth scopes required by the CLI command that is going to use the link. In this example, the resulting link is called `agent-app` which you later use with the command that requires this connected app, such as `agent preview`. ```bash sf org login web --client-app agent-app --username jdoe@example.com --client-id 3MVG9XgkMlongstring --scopes "sfap_api chatbot_api refresh_token api web" ``` Then use the new `--client-app` flag of the `agent preview` command to specify the link to the connected app. For example: ```bash sf agent preview --api-name "Resort_Manager" --client-app agent-app --target-org my-org ``` (sfdx-core PR [#1188](https://github.com/forcedotcom/sfdx-core/pull/1188), plugin-auth PR [#1306](https://github.com/salesforcecli/plugin-auth/pull/1306), plugin-agent PR [#157](https://github.com/salesforcecli/plugin-agent/pull/157)) * NEW: We're happy to announce that the Source Mobility feature is now generally available (GA)! With this feature you can move source files within your local Salesforce DX project without the source-tracking feature thinking that you've deleted and then recreated a metadata component. A few things to keep in mind: * Now that source mobility is GA, the feature is enabled by default. To opt-out of the behavior, set the new SF_DISABLE_SOURCE_MOBILITY environment variable to `true`; the variable is `false` by default. * We removed the old environment variable for opting into the Beta feature (SF_BETA_TRACK_FILE_MOVES). * Source Mobility works with file _moves_, not file _renames_. Renaming a source file is still interpreted as deleting a metadata component and creating a new one with the different name. * Child source files can move only to an identically named parent. For example, a custom field can move between Object folders in different package directories only if both Object folders have the same name. Enjoy reorganizing your DX project source files! (source-tracking PR [#778](https://github.com/forcedotcom/source-tracking/pull/778)) * NEW: Simplify your packaging push upgrades by leveraging the four new CLI commands that let you schedule, abort, view details on on a specific package upgrade, or view a list of all push upgrade jobs: * `package push-upgrade schedule`: Schedules a push upgrade for an unlocked or second-generation managed package. * `package push-upgrade abort`: Cancels a push upgrade request. * `package push-upgrade list`: Displays the status of all push upgrade requests for a specific package.. * `package push-upgrade report`: Displays detailed information for a specific push upgrade request. Push upgrades let you upgrade unlocked or second-generation managed packages installed in orgs, without asking customers to install the upgrade themselves. This example schedules a push upgrade that initiates at a specified time, and provides a list of org IDs to receive the package upgrade. ```bash sf package push-upgrade schedule --package 04txyz --start-time "2024-12-06T21:00:00" --org-list 00DAxx, 00DBx ``` * FIX: Decomposed workflows now play nice with other metadata in your DX project when deploying to an org. (GitHub issue [#3275](https://github.com/forcedotcom/cli/issues/3275), source-deploy-retrieve PR [#1571](https://github.com/forcedotcom/source-deploy-retrieve/pull/1571)) ## 2.92.7 (June 11, 2027) * NEW: The `package convert` command is now generally available. Package migrations let you convert an existing first-generation (1GP) package into a second-generation (2GP) package, and then migrate the 1GP package installed in subscriber orgs to 2GP. This example converts the latest managed-released version of the 1GP package with the specified package ID and gives it the installation key "password123"; the example uses the default Dev Hub org: ```bash sf package convert --package 033... --installation-key password123 ``` * NEW: The `agent generate template` command is now generally available. Use this command to generate an agent template from an existing agent in your DX project so you can then package the template in a managed package. For example: ```bash sf agent generate template --agent-file force-app/main/default/bots/My_Agent/My_Agent.bot-meta.xml --agent-version 1 ``` (plugin-agent PR [#152](https://github.com/salesforcecli/plugin-agent/pull/152)) * CHANGE: We converted the plugin that contains the `agent` commands ([`plugin-agent`](https://github.com/salesforcecli/plugin-agent)) from JIT to core. As a result, starting with this release, new installs of Salesforce CLI automatically include the plugin. (cli PR [#2254](https://github.com/salesforcecli/cli/pull/2254)) * FIX: Re-retrieving a custom object after adding a custom field using Salesforce UI now works correctly. (GitHub issues [#3300](https://github.com/forcedotcom/cli/issues/3300) and [#3301](https://github.com/forcedotcom/cli/issues/3301), plugin-deploy-retrieve PR [#1568](https://github.com/forcedotcom/source-deploy-retrieve/pull/1568)) ## 2.91.6 (June 4, 2025) * FIX: If you run a command that uses a SOAP API, such as `project deploy start`, and you have configured your connected app or external client app to issue JWT-based access tokens, the command now correctly fails and outputs an error message saying that the SOAP API doesn't support JWT-based access tokens. (GitHub issue [#3297](https://github.com/forcedotcom/cli/issues/3297), jsforce PR [#1698](https://github.com/jsforce/jsforce/pull/1698)) * FIX: If you set the SF_ORG_METADATA_REST_DEPLOY environment variable or the `org-metadata-rest-deploy` configuration variable to `true`, then org settings in the scratch org definition file are now deployed using the REST API instead of the default SOAP API. (sfdx-core PR [#1192](https://github.com/forcedotcom/sfdx-core/pull/1192)) ## 2.90.4 (May 28, 2025) * NEW: Enable Apex debug logging when you use the `agent preview` CLI command to converse with your agent with the new `--apex-debug` flag. For example: ```bash sf agent preview --api-name "Resort_Manager" --target-org my-org --connected-app-user my-agent-user --apex-debug ``` With this new flag, when any conversation message executes Apex code, a new Apex debug log file is written to the specified output directory, along with the transcript and response JSON files. See [Debug Apex Code](https://developer.salesforce.com/docs/platform/sfvscode-extensions/guide/apex-debugging.html) in the _Salesforce Extensions for Visual Studio Code_ guide for information about using these debug log files. (plugin-agent PR [#141](https://github.com/salesforcecli/plugin-agent/pull/141)) * FIX: When you run `project deploy start` with the `--verbose` flag, and also set the CI environment variable to `true`, the command output now includes the `Test Success` section, same as the human-readable output. (GitHub issue [#3291](https://github.com/forcedotcom/cli/issues/3291), GitHub discussion [#3242](https://github.com/forcedotcom/cli/discussions/3242), plugin-deploy-retrieve PR [#1358](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1358)) * FIX: We updated the directory name of the PricingRecipe metadata type in the [CLI registry](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json) to the correct `pricingRecipe`. (source-deploy-retrieve PR [#1565](https://github.com/forcedotcom/source-deploy-retrieve/pull/1565)) ## 2.89.8 (May 21, 2025) ANNOUNCEMENT: Agentforce DX is now generally available (GA)! Check out the [Build Agents with Agentforce DX](https://developer.salesforce.com/docs/einstein/genai/guide/agent-dx.html) documentation in the _Agentforce Developer Guide_. Enjoy! ----------------- * CHANGE: The `org open agent` command is now generally available; previously it was beta. Also, to maintain consistency across all agent-related commands, we changed the `--name` flag name to `--api-name`. For example, to open the agent with API name `Coral_Cloud_Agent` in your default org using your default browser, run this command: ```bash sf org open agent --api-name Coral_Cloud_Agent ``` (plugin-org PR [#1420](https://github.com/salesforcecli/plugin-org/pull/1420)) * CHANGE: The `agent preview` command is now beta; previously it was developer preview. (plugin-agent PR [#140](https://github.com/salesforcecli/plugin-agent/pull/140)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * DgtAssetMgmtProvider * DgtAssetMgmtPrvdLghtCpnt (GitHub issue [#3277](https://github.com/forcedotcom/cli/issues/3277), source-deploy-retrieve PR [#1561](https://github.com/forcedotcom/source-deploy-retrieve/pull/1561)) ## 2.88.6 (May 14, 2025) * CHANGE: We're excited to announce that these `agent` commands are now generally available; previously they were beta. * `agent create` : Create an agent in your org using a local agent spec file. * `agent generate agent-spec` : Generate an agent spec, which is a YAML file that captures what an agent can do. * `agent generate test-spec` : Generate an agent test spec, which is a YAML file that lists the test cases for testing a specific agent. * `agent test create` : Create an agent test in your org using a local test spec YAML file. * `agent test list` : List the available agent tests in your org. * `agent test results` : Get the results of a completed agent test run. * `agent test resume` : Resume an agent test that you previously started in your org so you can view the test results. * `agent test run` : Start an agent test in your org. The `agent generate template` command is still beta and the `agent preview` command is still developer preview. Also, to maintain consistency across all `agent` comamnds, we changed these flag names: * Command `agent create`: * The `--agent-api-name` flag is now `--api-name`. * The `--agent-name` flag is now `--name`. * Command `agent test create` * The `--test-api-name` flag is now `--api-name`. For example, to create an agent: ```bash sf agent create --name "Resort Manager" --api-name Resort_Manager --spec specs/resortManagerAgent.yaml --target-org my-org ``` To create an agent test: ```bash sf agent test create --spec specs/Resort_Manager-testSpec.yaml --api-name Resort_Manager_Test --force-overwrite --target-org my-org ``` (plugin-agent PR [#135](https://github.com/salesforcecli/plugin-agent/pull/135)) * FIX: Decomposing a permission set that grants access to multiple objects is now working correctly and as documented. (GitHub issue [#3233](https://github.com/forcedotcom/cli/issues/3233), source-deploy-retrieve PR [#1554](https://github.com/forcedotcom/source-deploy-retrieve/pull/1554)) ## 2.87.7 (May 7, 2025) * CHANGE: As we announced on [January 8, 2025](./README.md#2716-january-8-2025), we removed the `--bulk`, `--wait`, and `--async` flags of the `data query` command. We also removed the `data query resume` command. Use the `data export bulk|resume` commands instead. For example: ```bash sf data export bulk --query "SELECT Id, Name, Account.Name FROM Contact" --output-file export-accounts.csv --wait 10 --target-org my-scratch ``` (plugin-data PR [#1237](https://github.com/salesforcecli/plugin-data/pull/1237)) * FIX: We improved the help for `project retrieve start` by adding an example that shows how to use a wildcard to retrieve metadata components associated with a parent component, in this case list views for the Case standard object. It's not always obvious how to do this. (GitHub issue [#3266](https://github.com/forcedotcom/cli/issues/3266), plugin-deploy-retrieve [#1341](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1341)) ## 2.86.9 (April 30, 2025) * NEW: When refreshing a sandbox org with the `org refresh sandbox` command, you can now use the new `--source-id` or `--source-sandbox-name` flags to change its original source org to a new org. The refreshed sandbox org's metadata is then updated with the new source org's metadata. For example, this command refreshes the sandbox named `devSbx2` by changing its original source org to be a sandbox called `devSbx3`: ```bash sf org refresh sandbox --name devSbx2 --source-sandbox-name devSbx3 --target-org prodOrg ``` The value of `--source-id` and `--source-sandbox-name` must be an existing sandbox. The new source sandbox org, and the refreshed sandbox specified with the `--name` flag, must both be associated with the production org (`--target-org`) that contains the sandbox licenses. You can specify either `--source-id `or `--source-sandbox-name` when refreshing an existing sandbox, but not both. We also updated a related issue where specifying the new source sandbox in a sandbox definition file with the `sourceSandboxName` option returned an error when running `org refresh sandbox`. (GitHub issue [#3262](https://github.com/forcedotcom/cli/issues/3262), plugin-auth PR [#1396](https://github.com/salesforcecli/plugin-org/pull/1396)) * NEW: The [Agentforce DX](./README.md#2794-march-12-2025) commands, such as `agent create` and `agent test run` are now just-in-time (JIT). This means that when you update to this Salesforce CLI release and run an `agent` command, Salesforce CLI checks if the associated [plugin-agent](https://github.com/salesforcecli/plugin-agent) is installed. If it's not, Salesforce CLI automatically installs it and then runs your command. (cli PR [#2203](https://github.com/salesforcecli/cli/pull/2203)) * NEW: Run flow tests in your org with these new CLI commands, which are contained in the just-in-time (JIT) [plugin-flow](https://github.com/salesforcecli/plugin-flow) plugin: * `flow run test` : Invoke flow tests in an org. * `flow get test` : Display test results for a specific asynchronous test run. For example, this command runs all the tests associated with a flow in the org with alias `scratchOrg`; use the flow definition developer name to identify a flow: ```bash sf flow run test --target-org scratchOrg --class-names ``` Run the two commands with the `--help` flag to get more information and examples. The `plugin-flow` plugin isn't included in the core Salesforce CLI; instead, it's installed the first time you run one of its commands. * FIX: You can now correctly retrieve DigitalExperienceBundle metadata components with the `project retrieve start` command into a DX project that already contains these components. Previously you either got an error or they were retrieved into an incorrect directory. (source-deploy-retrieve PR [#1546](https://github.com/forcedotcom/source-deploy-retrieve/pull/1546) * FIX: Salesforce CLI now displays a warning when you run `org logout` on an org that you haven't authorized; previously it incorrectly displayed a success message. **NOTE**: Starting September 2025, the new warning will be converted to an error. As a result, the exit code when you try to log out of an unauthenticated org will change from 0 to 1. (GitHub issue [#3247](https://github.com/forcedotcom/cli/issues/3247), plugin-org PR [#1282](https://github.com/salesforcecli/plugin-auth/pull/1282)) * FIX: Salesforce DX projects now support the WorkflowFlowAutomation [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). (GitHub issue [#3202](https://github.com/forcedotcom/cli/issues/3202)) ## 2.85.7 (April 23, 2025) * CHANGE: Starting with this release, the `--async` flag of these commands is deprecated because the commands are asynchronous by default: * `data delete bulk` * `data export bulk` * `data import bulk` * `data query` * `data update bulk` * `data upset bulk` (plugin-data PR [#1222](https://github.com/salesforcecli/plugin-data/pull/1222)) * CHANGE: Over the next few releases we'll be changing our licenses from the [3-Clause BSD License](https://opensource.org/license/bsd-3-clause) to the [Apache License, Version 2.0](https://opensource.org/license/apache-2-0). (dev-scripts PR [#386](https://github.com/forcedotcom/dev-scripts/pull/386)) ## 2.84.6 (April 16, 2025) * NEW: If the `org create scratch` command times out before the scratch org is ready, you run the `org resume scratch` command to poll for completion and see the results. You can now specify how long the command waits before it returns control of the terminal to you with the new `--wait` flag; the output shows the progress of the scratch org create. Previously you had to keep running the `org resume scratch` command until the scratch org was ready. In this example the command waits for 10 minutes before returning control to you: ```bash sf org resume scratch --job-id 2SRfakefake000345 --wait 10 ``` (plugin-org PR [#1376](https://github.com/salesforcecli/plugin-org/pull/1376), sfdx-core PR [#1177](https://github.com/forcedotcom/sfdx-core/pull/1177)) * FIX: When used with metadata types that are always in a folder, the `--exclude-metadata` flag of `project generate manifest --from-org` now correctly excludes both the metadata components and their folders. Examples of metadata type that are always in folders include [Document](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_document.htm) and [Report](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_report.htm). (GitHub issue [#3232](https://github.com/forcedotcom/cli/issues/3232), source-deploy-retrieve PR [#1535](https://github.com/forcedotcom/source-deploy-retrieve/pull/1535)) * FIX: The `plugins discover` CLI command is now working as expected. (GitHub issue [#3238](https://github.com/forcedotcom/cli/issues/3238), plugin-marketplace PR [#457](https://github.com/salesforcecli/plugin-marketplace/pull/457)) * FIX: You can now correctly deploy and retrieve [CustomPermission](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_custompermission.htm) metadata components while also decomposing the custom permissions in the [PermissionSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm) component. (GitHub issue [#3220](https://github.com/forcedotcom/cli/issues/3220), source-deploy-retrieve PR [1534x](https://github.com/forcedotcom/source-deploy-retrieve/pull/1534)) ## 2.83.7 (April 9, 2025) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * FieldServiceMobileConfig * GenAiPlannerBundle ## 2.82.6 (April 2, 2025) * FIX: We improved the displayed error message when a problem occurs while authorizing an org, such as a keychain file has the wrong permissions. (GitHub issue [#3231](https://github.com/forcedotcom/cli/issues/3231), sfdx-core PR [#1175](https://github.com/forcedotcom/sfdx-core/pull/1175)) * FIX: When specifying flag values in a file and using `--flags-dir` to pass the flag values to a command, files that contain multiple lines can now correctly use both LF and CRLF line endings. (GitHub issue [#3236](https://github.com/forcedotcom/cli/issues/3236), cli PR [#2162](https://github.com/salesforcecli/cli/pull/2162)) ## 2.81.9 (March 26, 2025) * CHANGE: We removed the deprecated `--verbose` flag of `data delete bulk` and `data upsert bulk`; use the `data bulk results` command instead. In October 2024 we deprecated the flag and added the deprecation warning in the command output. (plugin-data PR [#1206](https://github.com/salesforcecli/plugin-data/pull/1206)) * CHANGE: We no longer include the records that failed after running `data delete|upsert bulk --json` in the JSON output; use the `data bulk results` command to get this information. We also removed the ability to resume synchronous data operations with the `data delete|upsert resume` commands. In October 2024 we deprecated both of these features and added the deprecation warning in the command outputs. (plugin-data PR [#1209](https://github.com/salesforcecli/plugin-data/pull/1209)) * CHANGE: When you open an org in a browser with the `org open` command but without `--json` or `--url-only`, Salesforce CLI now generates a single-use frontdoor URL. This URL can be used one time only; subsequent use won't allow you to log into the org. This change makes the access to your org more secure. Code Builder users: when you run `org open` without `--json` or `--url-only` in a Code Builder terminal, the URL to open an org in a browser is displayed, rather than a browser automatically starting; this is normal expected behavior. The new change in Code Builder behavior is that the outputted URL is now single-use only and expires in 60 seconds. Starting in August 2025, the generated URLs in the output of `org open --json` or `org open --url-only` will also be single-use only; until then the URLs continue to be multi-use. A warning is printed if you use the `--json` or `--url-only` flags of `org open` to remind you of the upcoming change. To immediately force the URLs in _all_ output of `org open` to be single-use, set the new SF_SINGLE_USE_ORG_OPEN_URL environment variable to `true`. For example: ```bash export SF_SINGLE_USE_ORG_OPEN_URL=true ``` (GitHub issue [#2769](https://github.com/forcedotcom/cli/issues/2769), plugin-org PR [#1375](https://github.com/salesforcecli/plugin-org/pull/1375)) * FIX: We improved the error message returned when you run the `apex run test` command but there are no Apex tests in your org; it now clearly states what the problem is. (GitHub issue [#3217](https://github.com/forcedotcom/cli/issues/3217), plugin-apex PR [#706](https://github.com/salesforcecli/plugin-apex/pull/706)) * FIX: We fixed the remaining bugs around the `Maximum call stack size exceeded` error that sometimes occurred when running `project generate manifest --from-org` on an org that has more than 1,000 folder metadata components, such as `ReportFolder` or `DashboardFolder`. (plugin-deploy-retrieve PR [#1314](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1314), source-deploy-retrieve PR [#1526](https://github.com/forcedotcom/source-deploy-retrieve/pull/1526)) ## 2.80.12 (March 19, 2025) * NEW: Easily create a scratch org from a snapshot with the new `--snapshot` flag of `org create scratch`. Snapshots are a point-in-time copy of a scratch org which you create with the `org create snapshot` command. With this new flag, you're no longer required to create a definition file when creating a scratch org from a snapshot. For example, let's say you previously created a snapshot called `NightlyBranch`. To create a new scratch org using this snapshot, run this command: ```bash sf org create scratch --alias my-scratch-org --target-dev-hub MyHub --snapshot NightlyBranch --wait 10 ``` In the example, the `MyHub` Dev Hub org must be associated with the `NightlyBranch` snapshot. We recommend you increase the wait time with the `--wait` flag because creating a scratch org from a snapshot can take a while. (plugin-org PR [#1358](https://github.com/salesforcecli/plugin-org/pull/1358)) * FIX: The `project generate manifest --from-org` command now runs successfully on orgs with over 100,000 metadata components. Previously, this command would result in an `Out of Memory` error. Additionally, to address issues with large numbers of folder metadata components, such as `EmailTemplateFolder`, we have set the default value of the `SF_LIST_METADATA_BATCH_SIZE` environment variable to `500`. This ensures the command completes correctly even when an org has more than 1,000 folder metadata components. Previously, the command would hang in such cases, even if the total number of components was less than 100,000. (GitHub issue [#3197](https://github.com/forcedotcom/cli/issues/3197), source-deploy-retrieve PR [#1511](https://github.com/forcedotcom/source-deploy-retrieve/pull/1511)) * FIX: The `org login web` command now gracefully returns an error if you use the `--browser` flag to specify a browser that isn't installed on your computer; previously the command would hang indefinitely. (GitHub issue [#1830](https://github.com/forcedotcom/cli/issues/1830), plugin-auth PR [#1260](https://github.com/salesforcecli/plugin-auth/pull/1260)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * DataObjectBuildOrgTemplate * InvocableActionExtension * LifeSciConfigCategory * LifeSciConfigRecord ## 2.79.4 (March 12, 2025) * NEW: (BETA) We’re thrilled to announce the beta release of Agentforce DX, a set of new Salesforce CLI commands and a Visual Studio Code (VS Code) extension that let you create, preview, and test agents directly in a Salesforce DX project. With Agentforce DX you can: * **Generate YAML Spec Files**—Use the `agent generate agent-spec|test-spec` CLI commands to generate simple YAML spec files that describe agents and agent tests. * **Create Agents and Agent Tests**—Pass these spec files as inputs to the `agent create` and `agent test create` CLI commands to create agents and agent tests in your development org. * **Run Agent Tests**—Execute agent tests in your org and view the results from either the VS Code testing panel or by running the `agent test run|results|resume|list` CLI commands. * **Interact with Active Agents**—Interact directly with active agents using the `agent preview` CLI command. (Developer Preview) The new CLI commands are in the `agent` topic and are part of the [`@salesforce/plugin-agent`](https://github.com/salesforcecli/plugin-agent) plugin. Install the plugin with this command: ```bash sf plugins install agent ``` Download and install the VS Code Agentforce DX extension from the [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-agents) or the [Open VSX Registry](https://open-vsx.org/extension/salesforce/salesforcedx-vscode-agents). Here are a few examples of what you can do with Agentforce DX. Generate an agent spec file that describes your new agent by providing some properties at the command line and be prompted for others; use your default org: ```bash sf agent generate agent-spec --type customer \ --role "Field customer complaints and manage employee schedules." \ --output-file specs/resortManagerAgent.yaml ``` Create the agent in your org by passing in the generated spec file: ```bash sf agent create --agent-name "Resort Manager" --spec specs/resortManagerAgent.yaml ``` Generate an agent test spec for testing this new agent; this command is interactive and prompts you for all the information: ```bash sf agent generate test-spec ``` Create an agent test in your org by passing in the generated test spec file: ```bash sf agent test create --spec specs/Resort_Manager-testSpec.yaml ``` Run the agent test in your org: ```bash sf agent test run --api-name Resort_Manager_Test ``` For more information, see: * [_Agentforce Developer Guide_: Agentforce DX](https://developer.salesforce.com/docs/einstein/genai/guide/agent-dx.html) * [_Salesforce CLI Command Reference_: agent Commands](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_agent_commands_unified.htm) We hope you enjoy these fun new commands! Known Issue: When generating the list of topics in an agent spec, the LLM sometimes includes dashes or other special characters in the topic names. These characters cause errors when creating an agent with the spec. Workaround: Be sure to use only underscores or alphanumeric characters in the topic names; spaces are fine. ## March 5, 2025 Due to [TDX 2025](https://www.salesforce.com/tdx/), we aren't releasing a new stable or stable-rc version today. Hope to see you at the conference! ## 2.78.3 (Feb 26, 2025) * NEW: When you run `project deploy start` with both `--test-level` and `--verbose`, the human-readable output now shows how long each Apex test took to run, in milliseconds. This information was already available in the JSON output. Here's sample output: ```bash Test Success [11] ✓ GeocodingServiceTest.blankAddress (159ms) ✓ FileUtilitiesTest.createFileFailsWhenIncorrectBase64Data (263ms) ✓ FileUtilitiesTest.createFileFailsWhenIncorrectFilename (227ms) ✓ FileUtilitiesTest.createFileFailsWhenIncorrectRecordId (481ms) ``` (GitHub discussion [#3194](https://github.com/forcedotcom/cli/discussions/3194), plugin-deploy-retrieve [#1286](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1286)) * FIX: The `project retrieve start --output-dir mydir` command now correctly writes single-file metadata components, such as GlobalValueSet, directly to the `mydir` directory; previously the command would incorrectly write them to `mydir/main/default`. (GitHub issue [#3177](https://github.com/forcedotcom/cli/issues/3177), plugin-deploy-retrieve PR [#1289](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1289)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * ContentTypeBundle * AnalyticsDashboard ## 2.77.6 (Feb 19, 2025) * NEW: When generating a manifest with the `project generate manifest` command, you can now use the `--metadata` flag together with `--source-dir` to target specific metadata components in your local package directory. This new feature is useful when you have multiple package directories or multiple directories within a single package directory and you want to target specific metadata within a source path. Similarly, you can also use `--excluded-metadata` with `--source-dir` to target all metadata in your local package directory _except_ the specified components. This example generates a manifest from the metadata components in the `force-app` package directory but excludes StandardValueSet components: ```bash sf project generate manifest --excluded-metadata StandardValueSet --source-dir force-app ``` (plugin-deploy-retrieve PR [#1280](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1280)) * FIX: All commands that run Apex tests, such as `project deploy start`, now correctly display the test failures in both human output and when run in continuous integration (CI) jobs. (plugin-deploy-retrieve PR [#1284](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1284)) * FIX: DigitalExperience metadata components are now retrieved into multiple package directories as expected in all scenarios. (source-deploy-retrieve PR [#1496](https://github.com/forcedotcom/source-deploy-retrieve/pull/1496)) * FIX: Salesforce DX projects now correctly support the existing GenAiFunction bundle [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). (GitHub issue [#3204](https://github.com/forcedotcom/cli/issues/3204), source-deploy-retrieve PR [1499](https://github.com/forcedotcom/source-deploy-retrieve/pull/1499)) * FIX: Salesforce DX projects now support the AnnotationExtensionSet [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.76.7 (Feb 12, 2025) * FIX: Piping the output of a Salesforce CLI command that produces very wide tables is now working correctly. (GitHub issue [#3206](https://github.com/forcedotcom/cli/issues/3206), oclif PR [#93](https://github.com/oclif/table/pull/93)) ## 2.75.5 (Feb 5, 2025) * NEW: (Beta) You can now decompose the [ExternalServiceRegistration](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_externalserviceregistration.htm) metadata component into two source files when you retrieve it to your Salesforce DX project, rather than retrieve a single monolithic metadata API format XML file. When you deploy to your org, the two files are re-converted into the one metadata API XML file. For example, let's say the name of your ExternalServiceRegistration metadata component `BankService`. The two source files after decomposition are: * `BankService.yaml` : A YAML file that contains the contents of the `schema` field. If the field's content is in JSON format in your org, it's always converted to YAML format when retrieved to your DX project. * `BankService.externalServiceRegistration-meta.xml` : A standard metadata API XML file that contains all the fields _except_ `schema`. Decomposing ExternalServiceRegistration metadata components is optional, so you must explicitly specify the behavior by running this command: ```bash sf project convert source-behavior --behavior decomposeExternalServiceRegistrationBeta ``` When the `project convert source-behavior` command finishes, your `sfdx-project.json` file is updated to always decompose ExternalServiceRegistration components. The existing source files in your local package directories are converted into the new decomposed format and you can deploy and retrieve your metadata as usual. To preview what the command does without making any changes, specify the `--dry-run` flag. See [Start Decomposing the Optional Metadata Types (Beta)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_decomposed_md_types.htm) for more information. The documentation will soon be updated with details about how ExternalServiceRegistration components are decomposed. (source-deploy-retrieve PR [#1493](https://github.com/forcedotcom/source-deploy-retrieve/pull/1493), plugin-deploy-retrieve PR [#1275](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1275)) * CHANGE: On January 31, 2025, Salesforce will retire Salesforce Functions, also known as Salesforce Elastic Services. See [Salesforce Functions Retirement](https://devcenter.heroku.com/articles/salesforce-functions-retirement) for more information. As a result, Salesforce CLI no longer JIT-installs the Salesforce Functions plugins (`plugin-env` and `plugin-functions`) and the Salesforce Functions commands, such as `run function start` aren't available by default. If you need these commands, you must install the [`plugins-functions`](https://github.com/salesforcecli/plugin-functions) and [`plugins-env`](https://github.com/salesforcecli/plugin-env) plugins manually using the `plugins install` command. We'll also soon remove the associated Salesforce Functions commands from the current version of the [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_functions_commands_unified.htm). If you need online reference information about the Salesforce Functions commands, see the [Winter '25 Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.252.0.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_functions_commands_unified.htm). (cli PR [#2093](https://github.com/salesforcecli/cli/pull/2093)) * FIX: The `force data bulk upsert` command now works correctly when upserting 10K+ records synchronously (specify the `--wait` flag) and using Node.js v22 or greater. (GitHub issue [#3180](https://github.com/forcedotcom/cli/issues/3180), plugin-data PR [#1172](https://github.com/salesforcecli/plugin-data/pull/1172)) * FIX: Salesforce DX projects now support the LightningTypeBundle [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.74.6 (Jan 29, 2025) * FIX: The `api request rest` command now correctly refreshes the access token if it has expired. (GitHub issue [#3176](https://github.com/forcedotcom/cli/issues/3176), sfdx-core PR [#1163](https://github.com/forcedotcom/sfdx-core/pull/1163), plugin-api PR [#62](https://github.com/salesforcecli/plugin-api/pull/62)) * FIX: If you run the `org create scratch` command with the `--json` flag, and the creation of the scratch org times out, its job ID is now included in the JSON output of the CLI command. (plugin-org PR [#1317](https://github.com/salesforcecli/plugin-org/pull/1317)) * FIX: If you installed Salesforce CLI on Windows using the installer, you no longer get the message that starts `(node:9801) [DEP0040] DeprecationWarning: The punycode module is deprecated.` when you run any CLI command. (GitHub issue [#3161](https://github.com/forcedotcom/cli/issues/3161), oclif PR [#1672](https://github.com/oclif/oclif/pull/1672)) ## 2.73.9 (Jan 22, 2025) * NEW: Ensure that your code adheres to best practices with these Code Analyzer v5 (Beta) commands in the just-in-time (JIT) `code-analyzer` plugin: * `code-analyzer config` : Display the current state of configuration for Code Analyzer. * `code-analyzer rules` : List the rules that are available to analyze your code. * `code-analyzer run` : Analyze your code with a selection of rules to ensure good coding practices. The `code-analyzer` plugin isn't included in the core Salesforce CLI; instead, it's now installed the first time you run one of its commands. The Code Analyzer v4 commands, such as `scanner run`, are also JIT and continue to work the same as before. Because the v4 and v5 commands are in separate CLI topics and plugins, they don't interfere with each other. We will stop JIT'ing the v4 `scanner` commands in the future, after the `code-analyzer` commands are generally available. See the [Salesforce Code Analzyer v5 (Beta)](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html) documentation for more information about how to use these new v5 commands to identify problems earlier in your development process. * FIX: When you opt to [decompose sharing rules](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_decomposed_md_types.htm), you can now deploy its children (such as SharingCriteriaRule) individually, rather than having to deploy the entire [SharingRules](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_sharingrules.htm) component with all its children. (source-deploy-retrieve PR [#1482](https://github.com/forcedotcom/source-deploy-retrieve/pull/1482)) * FIX: When you start decomposing permission sets by running the `project convert source-behavior --behavior decomposePermissionSetBeta2` command and retrieving the permission set from the org, and the permission set contains custom permissions, the corresponding XML file (`PermSetName.customPermissions-meta.xml`) is now valid. (GitHub issue [#3165](https://github.com/forcedotcom/cli/issues/3165), source-deploy-retrieve PR [#1483](https://github.com/forcedotcom/source-deploy-retrieve/pull/1483)) * FIX: You can now correctly retrieve metadata components whose types have non-unique suffixes. For example, both `RestrictionRule` and `ModerationRule` have the `.rule` suffix. (GitHub issue [#3168](https://github.com/forcedotcom/cli/issues/3168), source-deploy-retrieve PR [#1480](https://github.com/forcedotcom/source-deploy-retrieve/pull/1480)) * FIX: The `project deploy start` command now correctly returns an error when you specify a manifest with a typo for the `--manifest` flag and also specify the `--post|pre-destructive-changes` flags. (source-deploy-retrieve PR [#1481](https://github.com/forcedotcom/source-deploy-retrieve/pull/1481)) * FIX: Non-admin scratch org users can now successfully run `org display` when they specify their username for `--target-org`. (plugin-org PR [#1481](https://github.com/forcedotcom/source-deploy-retrieve/pull/1481)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * AnalyticsVisualization * AnalyticsVizViewDef * AnalyticsWorkspace ## 2.72.21 (Jan 15, 2025) * NEW: When generating a manifest from the metadata components in an org by running the `project generate manifest --from-org` command, you can now specify the metadata components you **don't** want to include with the new `--excluded-metadata` flag. For example, this command generates a manifest of all the metadata components except StandardValueSet from the org with alias `my-org`: ```bash sf project generate manifest --from-org my-org --excluded-metadata StandardValueSet ``` Use the existing `--metadata` flag with `--from-org` to specify the metadata components that you want to include in your manifest. For example: ```bash sf project generate manifest --from-org my-org --metadata ApexClass --metadata CustomObject ``` **Tip**: If your list of included or excluded metadata components is long, consider using `--flags-dir` to [specify the components in a file](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_flag_values_in_files.htm) rather than at the command-line. The `project generate manifest` command makes many concurrent API calls to discover the metadata that exists when generating a manifest from an org. To limit the number of concurrent requests, use the new SF_LIST_METADATA_BATCH_SIZE environment variable and set it to a size that works best for your org and environment. For example, to limit the number of concurrent API calls to 20: ```bash export SF_LIST_METADATA_BATCH_SIZE=20 ``` If you experience timeouts or inconsistent manifest contents, then setting this environment variable can improve accuracy. However, the command takes longer to run because it sends fewer requests at a time. (plugin-deploy-retrieve PR [#1247](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1247), source-deploy-retrieve PR [#1469](https://github.com/forcedotcom/source-deploy-retrieve/pull/1469)) * CHANGE: As we announced on [July 10, 2024](./README.md#2497-july-10-2024), we removed these two hidden commands: * `data import legacy tree` * `data export legacy tree` Use `data import|export tree` instead. (plugin-data PR [#1116](https://github.com/salesforcecli/plugin-data/pull/1116)) * FIX: The WorkFlowAction child metadata type of Workflow is now correctly decomposed into its own subdirectory in your DX project when you opt to [decompose workflows](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_decomposed_md_types.htm). Additionally, you can now deploy children of the [Workflow](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_workflow.htm) metadata type (such as WorkFlowAction) individually, rather than having to deploy the entire Workflow with all its children. Many thanks to [Matt Carvin](https://github.com/mcarvin8) for finding the bug, and then contributing the fix! We love your awesome initiative. (GitHub issue [#2563](https://github.com/forcedotcom/cli/issues/2563), source-deploy-retrieve PR [#1467](https://github.com/forcedotcom/source-deploy-retrieve/pull/1467)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * AiEvaluationDefinition * AiEvaluationTestSet * WorkflowFlowAction ## 2.71.6 (January 8, 2025) * CHANGE: Starting this release, the `--bulk`, `--wait`, and `--async` flags of the `data query` command are deprecated. The `data query resume` command is also deprecated because it works with only the `data query` command in bulk mode. All these deprecated flags and command will be removed from Salesforce CLI on April 25, 2025, or later. Use the `data export bulk|resume` commands instead. For example: ```bash sf data export bulk --query "SELECT Id, Name, Account.Name FROM Contact" --output-file export-accounts.csv --wait 10 --target-org my-scratch ``` (plugin-data PR [#1134](https://github.com/salesforcecli/plugin-data/pull/1134)) * FIX: We changed the running output of `project deploy start` to show test failures right away. As a result, you don’t need to wait for the entire deploy to finish before you decide how to handle the test failures. (GitHub issue [#3104](https://github.com/forcedotcom/cli/issues/3104), plugin-deploy-retrieve PR [#1215](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1215)) * FIX: The `data bulk` commands, when importing from a CSV file, default to the COMMA delimiter if they can't find the delimiter used in the CSV file. (plugin-data PR [#1151](https://github.com/salesforcecli/plugin-data/pull/1151)) * FIX: The `data import tree` command no longer fails when importing over 2K records. (GitHub [comment](https://github.com/forcedotcom/cli/issues/2738#issuecomment-2375750110), plugin-data PR [#1146](https://github.com/salesforcecli/plugin-data/pull/1146)) ## December 25, 2024 AND January 1, 2025 Due to the holiday break, we aren't releasing a new stable version these two weeks. Happy holidays! ## 2.70.7 (December 18, 2024) * NEW: Write the output of an executed SOQL query to a file with the new `--output-file` flag of the `data query` command. This new flag works only with CSV (comma-separated values) and JSON output, so you must use it in combination with `--result-format csv|json`. This example executes a SOQL query in an org with alias `my-scratch` and writes the JSON results to a file called `query-output.json`: ```bash sf data query --query "SELECT Id, Name, Account.Name FROM Contact" --output-file query-output.json --result-format json --target-org my-scratch ``` (plugin-data PR [#1135](https://github.com/salesforcecli/plugin-data/pull/1135)) * FIX: The `org refresh|resume sandbox` commands no longer output the erroneous error `INSUFFICIENT_ACCESS: use of the Metadata API requires a user with the ModifyAllData or ModifyMetadata permissions​` after they finish executing. The error was incorrect because users who refresh or resume sandboxes don't need those permissions. The refresh and resume of the sandbox always finished correctly, despite that error. (GitHub issue [#3048](https://github.com/forcedotcom/cli/issues/3048), plugin-org PR [#1276](https://github.com/salesforcecli/plugin-org/pull/1276)) * FIX: The `data export bulk` command no longer fails when exporting a very large dataset, such as millions of records, to a JSON-formatted output file. (GitHub issue [#3138](https://github.com/forcedotcom/cli/issues/3138), plugin-data PR [#1140](https://github.com/salesforcecli/plugin-data/pull/1140)) ## 2.69.14 (December 11, 2024) * NEW: Specify the line endings used in the comma-separated values (CSV) file when you run the `data delete|upsert bulk` commands with the new `--line-ending` flag. The default value on Windows is `CRLF`; on macOS and Linux it's `LF`. Similarly, specify the column delimiters in the CSV file when you run `data upsert bulk` with the new `--column-delimiter` flag; possible values include `BACKQUOTE`, `CARET`, and more. For example: ```bash sf data upsert bulk --sobject Contact --file contacts.csv --external-id Id --line-ending LF --column-delimiter CARET ``` (GitHub discussion #[2947](https://github.com/forcedotcom/cli/discussions/2947), plugin-data PR [#1110](https://github.com/salesforcecli/plugin-data/pull/1110)) * FIX: Salesforce CLI no longer outputs the message that starts `(node:9801) [DEP0040] DeprecationWarning: The `punycode` module is deprecated.` when you're using Node.js v22 or greater and you run any CLI command. (GitHub issue [#2535](https://github.com/forcedotcom/cli/issues/2535), salesforce/cli PR [#1971](https://github.com/salesforcecli/cli/pull/1971)) ## 2.68.6 (December 4, 2024) * NEW: (BETA) Open an agent in the Agent Builder UI with the new `open org agent` command. Use the `--name` flag to open an agent using its API name. For example: ```bash sf open org agent --name Coral_Cloud_Agent ``` To find the agent's API name, go to Setup in your org and navigate to the agent's details page. (plugin-org PR [#1264](https://github.com/salesforcecli/plugin-org/pull/1264)) * FIX: We improved the table output when `project deploy start` fails due to an metadata validation error. We now provide the name of the metadata type that's causing the error in the `Type` column. (GitHub issue [#3110](https://github.com/forcedotcom/cli/issues/3110), plugin-deploy-retrieve PR [#1217](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1217)) * FIX: If you set your `target-org` configuration variable to a sandbox, and then run `org delete scratch` without specifying the `--target-org` flag, the command now returns an error. Previously the command would delete the sandbox. (GitHub issue [#3058](https://github.com/forcedotcom/cli/issues/3058), plugin-org PR [#1257](https://github.com/salesforcecli/plugin-org/pull/1257)) ## Nov 27, 2024 Due to the Thanksgiving break in the United States, we aren't releasing a new stable version. Happy Thanksgiving! ## 2.67.7 (November 20, 2024) * FIX: We updated the `--help` of `apex test run` to say that users who run the command must have the View All Data system permission. (plugin-apex PR [#630](https://github.com/salesforcecli/plugin-apex/pull/630)) ## 2.66.7 (November 13, 2024) * NEW: Bulk update many records of a Salesforce object from a comma-separated values (CSV) file with the new `data update bulk` command. All the records in the CSV file must be for the same Salesforce object and the first column of every line must be an ID of the record you want to update. The CSV file can contain only existing records; if a record in the file doesn't currently exist in the Salesforce object, the command fails. Use the `--sobject` flag to specify the Salesforce object. See [Prepare Data to Ingest](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/datafiles_prepare_data.htm) in the "Bulk API 2.0 and Bulk API Developer Guide" for details about creating the CSV file. For example, this command updates Account records from the `accounts.csv` file in an org with alias "my-scratch": ```bash sf data update bulk --file accounts.csv --sobject Account --wait 10 --target-org my-scratch ``` Bulk updates can take a while, depending on how many records are in the CSV file. If the command times out after the specified wait time (10 minutes in our example), it displays a job ID that you then pass to the new `data update resume` command to see the status and results of the original update. For example: ```bash sf data update resume --job-id 750xx000fake005sAAA ``` (plugin-data PR [#1098](https://github.com/salesforcecli/plugin-data/pull/1098)) * NEW: Get the results of a previously run and completed bulk ingest (import, update, upsert, or delete) job with the new `data bulk results` command. The command works for jobs executed with Bulk API 2.0, such as a CLI command like `data import bulk` or an external tool like Data Loader, as long as the job provides a job ID. Pass the job ID to `data bulk results` to retrieve the results. The command displays information such as the job status, the ingest operation, updated Salesforce object, how many records were processed, and how many failed or succeeded. Finally, the output displays the names of the generated CSV-formatted files that contain the specific results for each ingested record. For example: ```bash sf data bulk results --job-id 7507i000fake341G --target-org my-scratch ``` (GitHub discussion [#2387](https://github.com/forcedotcom/cli/discussions/2387), plugin-data PR [#1097](https://github.com/salesforcecli/plugin-data/pull/1097)) * NEW: Specify the ID of the sandbox you want to clone with the new `--source-id` flag of the `org create sandbox` command. We also added a similar new option `sourceId` to the sandbox definition file. As always, the flag takes precendence if you specify both. This example shows how to clone an existing sandbox with ID `00Dxygfake` and name the new sandbox `NewClonedSandbox`; the org with the sandbox license has the alias `prodOrg`: ```bash sf org create sandbox --source-id 00Dxygfake --name NewClonedSandbox --target-org prodOrg --alias MyDevSandbox --set-default ``` For consistency, we also changed the name of the existing `--clone` flag of `org create sandbox` to `--source-sandbox-name`. Don't worry, we aliased the old `--clone` flag name to `--source-sandbox-name`, although we highly recommend you update your scripts to use the new flag name as soon as possible. (plugin-org PR [#1237](https://github.com/salesforcecli/plugin-org/pull/1237)) * NEW: Customize how the new [table-formatted command output](README.md#2646-october-30-2024) looks like with these new environment variables: * `SF_NO_TABLE_STYLE`: Removes all table stylings, such as borders and colors. * `SF_TABLE_OVERFLOW`: Specifies how to handle text in table output that is too wide for its column, such as by wrapping or truncating. * `SF_TABLE_BORDER_STYLE`: Specifies how to display the borders of table output, such as whether the table has an outline or vertical lines between columns. See [Salesforce CLI Environment Variables](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_env_variables.htm) for the possible and default values. * NEW: Specify the column deliminator used in the CSV file when running `data import bulk` with the new `--column-delimiter` flag. If you don't specify `--column-delimiter`, Salesforce CLI determines the delimiter used in the CSV file automatically. Run `sf data import bulk -h` to see the list of possible values. (plugin-data PR [#1098](https://github.com/salesforcecli/plugin-data/pull/1098)) * CHANGE: We upgraded the version of Node.js bundled in the Salesforce CLI operating system-specific installers, TAR files, and Docker images to v22. We always bundle the Active LTS version of Node.js in tandem with its [release schedule](https://github.com/nodejs/release?tab=readme-ov-file#release-schedule), and v22 went LTS on October 29, 2024. * FIX: When deploying or retrieving metadata, Salesforce CLI no longer attempts to resolve an XML file in the package directory that isn't part of a source component. As a result, you can include XML files in your package directory that aren't related to org metadata, add them to your `.forceignore` file, and deploys and retrieves will work as expected. (source-deploy-retrieve PR [#1452](https://github.com/forcedotcom/source-deploy-retrieve/pull/1452)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * AppFrameworkTemplateBundle * ChoiceList * ConvIntelligenceSignalRule * PublicKeyCertificate * PublicKeyCertificateSet ## 2.65.8 (November 6, 2024) * NEW: We updated these commands to use [multi-stage output](README.md#2639-october-23-2024), so while they are running they now display the stage they're currently on, the elapsed time, and more: * `project delete source` * `project deploy start` * `project deploy resume` * `project deploy validate` * `project deploy report` * `project retrieve start` Also, as a result of [this GitHub feedback](https://github.com/forcedotcom/cli/issues/3079), we changed how this multi-stage output displays in a continuous integration (CI) environment. Specifically: * The command polls for status updates every 5 seconds by default. You can change this interval with the new `SF_CI_UPDATE_FREQUENCY_MS` environment variable. For example, to poll every 10 seconds, set `SF_CI_UPDATE_FREQUENCY_MS=10000`. This environment variable works only in a CI environment. * Status messages, such as `Components: 21/30 (70%)` which shows how many components have been deployed to the org, are displayed only when information changes. * If 5 minutes goes by without an update, then the last status message is displayed again. You can change this interval with the new `SF_CI_HEARTBEAT_FREQUENCY_MS` environment variable. For example, to specify 10 minutes, set `SF_CI_HEARTBEAT_FREQUENCY_MS=600000`. This environment variable works only in a CI environment. (oclif multi-stage-output PR [#52](https://github.com/oclif/multi-stage-output/pull/52)) * CHANGE: As we [announced back in July 2024](https://github.com/forcedotcom/cli/issues/2974), we removed these deprecated commands from this release of Salesforce CLI: * `force:mdapi:convert` * `force:mdapi:deploy` * `force:mdapi:deploy:cancel` * `force:mdapi:deploy:report` * `force:mdapi:describemetadata` * `force:mdapi:listmetadata` * `force:mdapi:retrieve` * `force:mdapi:retrieve:report` * `force:source:convert` * `force:source:delete` * `force:source:deploy` * `force:source:deploy:cancel` * `force:source:deploy:report` * `force:source:ignored:list` * `force:source:manifest:create` * `force:source:open` * `force:source:pull` * `force:source:push` * `force:source:retrieve` * `force:source:status` * `force:source:tracking:clear` * `force:source:tracking:reset` If you haven't yet migrated to the new `sf` commands, see the [Migration Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_migrate.htm) for details. In particular: * [Map the old `sfdx` commands to their new `sf` equivalents.](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_old_new_command_mapping.htm) * [Read details and examples for migrating the `force:mdapi:*` and `force:source:*` commands.](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_mig_deploy_retrieve.htm) * [Read details and examples for migrating the `force:org:*` commands.](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_mig_org.htm) Finally, if you're not ready to migrate, see [this pinned issue](https://github.com/forcedotcom/cli/issues/2974) for workarounds. (source-deploy-retrieve PR [#1446](https://github.com/forcedotcom/source-deploy-retrieve/pull/1446), plugin-deploy-retrieve PR [#1197](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1197), cli PR [#1962](https://github.com/salesforcecli/cli/pull/1962), plugin-org PR [#1244](https://github.com/salesforcecli/plugin-org/pull/1244)) * FIX: If you run `data export tree` to export records from a Salesforce object that has a RecordType field, and you specify `RecordType.Name` in the SOQL query, you can now import that data using `data import tree` into a new org and the RecordType IDs and Names are correctly resolved. (GitHub discussion [#2753](https://github.com/forcedotcom/cli/discussions/2753), plugin-data PR [#1102](https://github.com/salesforcecli/plugin-data/pull/1102)) ## 2.64.6 (October 30, 2024) * NEW: Import a large number of records into a Salesforce object from a comma-separated values (CSV) file with the new `data import bulk` command. All the records in the CSV file must be for the same Salesforce object; see [Prepare Data to Ingest](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/datafiles_prepare_data.htm) in the "Bulk API 2.0 and Bulk API Developer Guide" for details about creating the CSV file. Use the `--sobject` flag to specify the Salesforce object. For example, this command imports Account records from the `accounts.csv` file into an org with alias "my-scratch": ```bash sf data import bulk --file accounts.csv --sobject Account --wait 10 --target-org my-scratch ``` Bulk imports can take a while, depending on how many records are in the CSV file. If the command times out after the specified wait time (10 minutes in our example), it displays a job ID that you then pass to the new `data import resume` command to see the status and results of the original export. For example: ```bash sf data import resume --job-id 750XXX00fake1222 ``` (GitHub issue [#2254](https://github.com/forcedotcom/cli/issues/2254) and discussion [#2339](https://github.com/forcedotcom/cli/discussions/2339), plugin-data PR [#1091](https://github.com/salesforcecli/plugin-data/pull/1091)) * NEW: Easily export records from a junction object and its parent objects by specifying multiple `--query` flags of the `data export tree` command; previously you could specify only one `--query` flag. A [junction object](https://help.salesforce.com/s/articleView?id=sf.relationships_manytomany.htm&type=5) is a custom Salesforce object with two master-detail relationships which you use to model a “many-to-many” relationship between two objects. We recommend that you also specify `--plan` when you run the export. After the export completes, you have a set of sObject tree files and a plan definition file to easily import the records of the junction object and its parent objects into a new org and preserve the many-to-many relationships. For example, the AccountContactRelation and AccountContactRole junction objects represents two many-to-many relationships between Contacts and Accounts. To export records from the two junction objects, along with associated Contact and Account records, and preserve the relationships, you could run something like this: ```bash sf data export tree --plan --output-dir junction \ --query "select AccountId, ContactId from AccountContactRole" \ --query "Select ID, AccountId, FirstName, LastName from Contact" \ --query "select ID, ContactId, AccountId from AccountContactRelation" \ --query "select ID, Name from Account where Name != 'Sample Account for Entitlements'" ``` (plugin-data PR [#1092](https://github.com/salesforcecli/plugin-data/pull/1092)) * CHANGE: oclif now uses [ink](https://www.npmjs.com/package/ink) to display tables in human-readable output, making the tables more visually appealing and easier to read. Here's the new [oclif table](https://github.com/oclif/table) GitHub repo. Over the next few releases we'll update the Salesforce CLI commands that display table output to use this new feature. For example, in this release we updated [plugin-limits](https://github.com/salesforcecli/plugin-limits/pull/1026) which contains the command `org list limits`. The old output looked like this: ```bash sf org list limits --target-org my-scratch Name Remaining Max ─────────────────────────────────────────── ───────── ───────── AnalyticsExternalDataSizeMB 40960 40960 CdpAiInferenceApiMonthlyLimit 500000000 500000000 ConcurrentAsyncGetReportInstances 200 200 ConcurrentEinsteinDataInsightsStoryCreation 5 5 ... ``` The new output looks like this: ```bash sf org list limits --target-org my-scratch ┌─────────────────────────────────────────────┬───────────┬───────────┐ │ Name │ Remaining │ Max │ ├─────────────────────────────────────────────┼───────────┼───────────┤ │ AnalyticsExternalDataSizeMB │ 40960 │ 40960 │ │ CdpAiInferenceApiMonthlyLimit │ 500000000 │ 500000000 │ │ ConcurrentAsyncGetReportInstances │ 200 │ 200 │ │ ConcurrentEinsteinDataInsightsStoryCreation │ 5 │ 5 │ ... ``` Much prettier! ## 2.63.9 (October 23, 2024) * NEW: Get a behind-the-scenes look at what happens when you execute certain CLI commands with the new multi-stage output feature. For example, when you execute `org create scratch`, you now see this output while the command is executing: ```bash $ sf org create scratch --edition developer --alias my-scratch-org ────────────── Creating Scratch Org ────────────── ✔ Prepare Request 37ms ✔ Send Request 14.61s ◯ Wait For Org - Skipped ✔ Available 5ms ⢿ Authenticate 1.46s ◼ Deploy Settings ◼ Done Request Id: 2SRWs000002aOttOAE OrgId: 00DOv00000C6RbJ Username: test-p4bh29a7jcvc@example.com Alias: my-scratch-org Elapsed Time: 16.21s ``` Checkmarks let you know when each stage completes and how long it took, with the total elapsed time counter at the bottom. Pretty cool, huh. These commands have been updated to use this new output: * `org create scratch` * `org resume scratch` (plugin-org PR [#1203](https://github.com/salesforcecli/plugin-org/pull/1203), oclif [multi-stage-output](https://github.com/oclif/multi-stage-output)) * NEW: Open a local metadata file in its associated builder in your org, such as Agent Builder, with the improved `--source-file` flag of `org open`. Let's say, for example, that you completed the Trailhead [Quick Start: Build Your First Agent with Agentforce](https://trailhead.salesforce.com/content/learn/projects/quick-start-build-your-first-agent-with-agentforce). The Coral Cloud Agent that you built was so cool that you decided to retrieve its associated metadata to a local DX project. To then quickly open the agent back up in Agent Builder, simply run this CLI command: ```bash sf org open --source-file force-app/main/default/bots/Coral_Cloud_Agent/Coral_Cloud_Agent.bot-meta.xml --target-org ``` You can also use the `--source-file` flag to open local metadata in Flow Builder, Apex Classes Setup page, and more. (plugin-org PR [#1230](https://github.com/salesforcecli/plugin-org/pull/1230)) * NEW: We now display the Lightning deploy URL, in addition to the deploy ID, when you run any of the `project deploy` commands with the `--verbose` flag. For example, when you run `project deploy start --verbose`, you now see a Deploy URL entry in the output: ```bash ... Status: Succeeded Deploy ID: 0AfRKfake00WH0A3 Target Org: test-ztqm4gogmflt@example.com Deploy URL: https://customer-fake.scratch.my.salesforce.com/lightning/setup/DeployStatus/page?address=%2Fchangemgmt%2Fmonitlotsofstuff.apexp ... ``` Many thanks to [Matt Carvin](https://github.com/mcarvin8) for contributing this useful new feature. It was your first contribution, but we sure hope it won't be your last! * FIX: The `sf plugins --json` command no longer fails in certain circumstances with a `TypeError`. (GitHub issue [#3051](https://github.com/forcedotcom/cli/issues/3051), oclif core PR [#1216](https://github.com/oclif/core/pull/1216)) ## 2.62.6 (October 16, 2024) * NEW: Export a large number of records from an org with the new `data export bulk` command. Use a SOQL query to select the fields and records that you want to export, and specify whether you want to write to a CSV- or JSON-formatted file. For example, this command exports the `Id`, `Name`, and `Account.Name` fields of the Contact object into a JSON-formatted file: ```bash sf data export bulk --query "SELECT Id, Name, Account.Name FROM Contact" --output-file export-accounts.json --result-format json --wait 10 --target-org my-scratch ``` Bulk exports can take a while, so if the command times out after the specified wait time (10 minutes in our example), it displays a job ID that you then pass to the new `data export resume` command to see the status and results of the original export. For example: ```bash sf data export resume --job-id 750XXX00fake1222 ``` IMPORTANT: The `data export bulk` command uses Bulk API 2.0, which is optimized to handle very large sets of data asynchronously. However, the API limits the type of SOQL queries you can run. For example, you can't use aggregate functions such as `count()`. For the complete list of limitations, see the "SOQL Considerations" section at the end of [this page](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm). (plugin-data PR [#1035](https://github.com/salesforcecli/plugin-data/pull/1035)) * NEW: Salesforce CLI now warns you when you deploy metadata with the `project deploy start` command and either the total size of the metadata or the number of metadata files is over 80% of the [Metadata API limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_metadata.htm). You can change this threshold by setting the new `SF_DEPLOY_SIZE_THRESHOLD` environment variable to a number between 1 and 100. For example, if you set `SF_DEPLOY_SIZE_THRESHOLD=70`, you get the warning when you try to deploy metadata that's over 70% of the limit. Salesforce CLI always attempts to deploy the metadata when you run the `project deploy start` command, even if it determines that the size or file count might be over the limit. (source-deploy-retrieve PR [#1435](https://github.com/forcedotcom/source-deploy-retrieve/pull/1435)) * NEW: Store the values for the HTTP request (header, body, etc) in a file when you run the `api request rest` command with the new `--file` flag. The command allows you to make an authenticated HTTP request using the Salesforce REST API. This flag is useful if you want to put the request information in a single JSON-formatted file rather than specify all the sections using flags, such as `--header`, `--body`, and so on. For example: ```bash sf api request rest --file ./myHttpRequest.json ``` Run `sf api request rest --help` and read the long description for the `--file` flag for information on how to create the file. (plugin-api PR [#14](https://github.com/salesforcecli/plugin-api/pull/14)) * NEW: Easily see which Salesforce CLI versions you previously downloaded with the new Download column in the `sf update --available` output. To see the Location column, you must now use the new `--verbose` flag along with the `--available` flag. We also made some minor formatting tweaks to the table output. (oclif plugin-plugins [#980](https://github.com/oclif/plugin-plugins/pull/980), plugin-update [#932](https://github.com/oclif/plugin-update/pull/932), plugin-commands [#763](https://github.com/oclif/plugin-commands/pull/763)) * FIX: The `force lightning lwc test run` command now correctly returns a non-zero exit code if a Lightning Web Component Jest test fails. (GitHub issue [#2991](https://github.com/forcedotcom/cli/issues/2991), plugin-lwc-test PR [#193](https://github.com/salesforcecli/plugin-lwc-test/pull/193)) * FIX: The Apex Code Coverage percentages displayed in the output of `sf project deploy start --test-level --coverage-formatters ` now match the percentages in the code coverage reports, such as `coverage-summary.json`. (GitHub issue [#3030](https://github.com/forcedotcom/cli/issues/3030), plugin-deploy-retrieve [#1175](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1175)) * FIX: (This fix is mostly interesting to `oclif` users, such as Salesforce CLI plugin developers). When you generate a `README.md` file for your plugin using `oclif readme`, flags that have the `noCacheDefault: false` option no longer display any locally set configuration variable values, similar to how `--help` works. (GitHub issue [#3041](https://github.com/forcedotcom/cli/issues/3041), oclif core PR [#1212](https://github.com/oclif/core/pull/1212), oclif oclif PR [#1566](https://github.com/oclif/oclif/pull/1566)) * FIX: The `project retrieve start --package-name` command now correctly retrieves packages that contain custom objects. (GitHub issue [#2977](https://github.com/forcedotcom/cli/issues/2977), source-deploy-retrieve PR [#1431](https://github.com/forcedotcom/source-deploy-retrieve/pull/1431)) ## 2.61.8 (October 9, 2024) * NEW: Download and install Salesforce CLI on Windows ARM64 computers with our new `sf-arm64.exe` installer. We're in the process of updating the [download page](https://developer.salesforce.com/tools/salesforcecli) with this new option, but in the meantime you can download the `stable` executable [here](https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-arm64.exe). (oclif PR [#1559](https://github.com/oclif/oclif/pull/1559)) * NEW: When you create a sandbox with the `org create sandbox` command, you can now specify the public group of Salesforce users that can access the sandbox by including either the `activationUserGroupId` or `activationUserGroupName` option (but not both) in the sandbox definition file. This example specifies that the Salesforce public user group with name `ExpertUsers` can access the sandbox after it's created: ``` { "sandboxName": "dev1", "licenseType": "Developer", "activationUserGroupName": "ExpertUsers" } ``` You can also now specify the name of the Apex class that runs after each copy of the sandbox with the new `apexClassName` option. Previously you could specify it only with an ID (`apexClassId`). (plugin-org PR [#1221](https://github.com/salesforcecli/plugin-org/pull/1221)) * NEW: Get detailed coverage results about an asynchronous test run by specifying the new `--detailed-coverage` flag of the `apex get test` command. Similar to how the `apex run test` command works, you must specify human-readable result format (the default) when you use the `--detailed-coverage` flag. For example: ```bash sf apex get test --test-run-id --code-coverage --detailed-coverage --result-format human ``` (plugin-apex PR [#597](https://github.com/salesforcecli/plugin-apex/pull/597)) * FIX: We fixed a source tracking issue with some metadata types, such as EmailTemplateFolder. (GitHub issue [#2902](https://github.com/forcedotcom/cli/issues/2902), source-tracking PR [#679](https://github.com/forcedotcom/source-tracking/pull/679)) * FIX: Salesforce DX projects now support the ExtlClntAppSamlConfigurablePolicies [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.60.13 (October 2, 2024) * CHANGE: We shipped `decomposePermissionSetBeta` back in [April](README.md#2368-april-10-2024), asked you to [vote on a new design of the feature](https://github.com/forcedotcom/cli/discussions/2993) (thank you), and we now have a winner! We went with option 2 (focused decomposition); see details [here](https://github.com/forcedotcom/cli/discussions/2993#discussioncomment-10431670). We now have a new source behavior value: `decomposePermissionSetBeta2`. If you haven't played with source decomposition at all yet, you can try it by running `sf project convert source-behavior --behavior decomposePermissionSetBeta2`. You can also use this command if you previously updated your project to use the original `decomposePermissionSetBeta` flavor, but you now want to try out the new stuff. Enjoy! (source-deploy-retrieve PR [#1412](https://github.com/forcedotcom/source-deploy-retrieve/pull/1412)) * FIX: Deploying a sharing rule by specifying one of its child metadata types (such as `project deploy start --metadata SharingCriteriaRule:Account.Test_Rule1`) now works correctly. (source-deploy-retrieve PR [#1419](https://github.com/forcedotcom/source-deploy-retrieve/pull/1419)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * ExtlClntAppPushSettings * ExtlClntAppPushConfigurablePolicies ## 2.59.6 (September 25, 2024) * FIX: We fixed some under-the-hood bugs. ## 2.58.7 (September 11, 2024) * FIX: Salesforce CLI now supports these environment variables: `SF_DISABLE_SOURCE_MEMBER_POLLING` and `SF_SOURCE_MEMBER_POLLING_TIMEOUT`. Previously only their `SFDX_` equivalents were supported. (GitHub [comment](https://github.com/forcedotcom/cli/issues/2974#issuecomment-2322907656), source-tracking PR [#668](https://github.com/forcedotcom/source-tracking/pull/668)) ## 2.57.7 (September 4, 2024) * NEW: The `project deploy start` command now reports the zip size and zip file count when using the `--verbose` flag. (GitHub Discussion [#2942](https://github.com/forcedotcom/cli/discussions/2942), plugin-deploy-retrieve PR [#1138](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1138)) * NEW: We've improved the `doctor` command so it now checks whether you are setting proxy env vars correctly (plugin-info PR [#848](https://github.com/salesforcecli/plugin-info/pull/848)) * NEW: Try the new BETA `api request graphql` command to send GraphQL requests to your org! (plugin-api PR [#6](https://github.com/salesforcecli/plugin-api/pull/6)) - `sf api request graphql --body "query accounts { uiapi { query { Account { edges { node { Id \n Name { value } } } } } } }"` - `cat body.txt | sf api request graphql --body -` - Stream results to a file with the `--stream-to-file` flag - Run `sf api request graphql --help` to see more examples * FIX: String Replacement logic will explicitly skip binary files even if they are included in the glob pattern. (source-deploy-retrieve PR [#1405](https://github.com/forcedotcom/source-deploy-retrieve/pull/1405)) ## 2.56.7 (August 28, 2024) * NEW: Try the new BETA `api request rest` command to send REST calls to your org! ([plugin-api repo](https://github.com/salesforcecli/plugin-api)) - `sf api request rest sobjects/account/ --method PATCH --body "{\"Name\": \"Updated\"}"` - `sf api request rest sobjects/account/ --method PATCH --body body.txt` - `cat body.txt | sf api request rest sobjects/account --body -` - Stream results to a file with the `--stream-to-file` flag - Run `sf api request rest --help` to see more examples * NEW: The `apex run test` and `apex get test` commands now have a new `--concise` flag. Setting this flag for `apex run test` or `apex get test` will suppress passing test results and the code coverage table. Only failing tests and the summary table will be displayed. (plugin-apex PR [#504](https://github.com/salesforcecli/plugin-apex/pull/504), GitHub Issue [#243](https://github.com/forcedotcom/salesforcedx-apex/issues/243), GitHub Discussion [#2872](https://github.com/forcedotcom/cli/discussions/2872)) Many thanks to [Kyle Capehart](https://github.com/k-capehart) for contributing this useful new flag! * NEW: The `sf project convert source-behavior` command will now warn if you have uncommitted work before doing project modifications. Note that this command puts components in a newly created `main/default` folder in each package directory. You might need to re-organize them into your preferred structure. (plugin-deploy-retrieve PR [#1130](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1130)) * CHANGE: We shipped `decomposeCustomLabelsBeta`, got [feedback](https://github.com/forcedotcom/cli/issues/2840) (thank you!), and decided to change how it behaves. You can see the design proposal [here](https://github.com/forcedotcom/cli/discussions/2948). It removes an extra folder layer that other decomposition strategies needed and supports more flexible folder structures. Now there's `decomposeCustomLabeltsBeta2`. If you haven't used it yet, you can try it via `sf project convert source-behavior --behavior decomposeCustomLabelsBeta2`. This works if your project isn't using a preset OR if you started using the original flavor of `decomposeCustomLabeltsBeta`. Please keep the feedback coming! (source-deploy-retrieve PR [#1392](https://github.com/forcedotcom/source-deploy-retrieve/pull/1392)) * CHANGE: You can now run these packaging commands outside of a Salesforce DX project: * `package delete` * `package update` * `package version delete` * `package version displayancestry` * `package version list` * `package version promote` * `package version report` (plugin-packaging PR [#771](https://github.com/salesforcecli/plugin-packaging/pull/771), packaging PR [#638](https://github.com/forcedotcom/packaging/pull/638)) * FIX: Salesforce DX projects now support the GenAiFunction [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json) (source-deploy-retrieve PR [#1404](https://github.com/forcedotcom/source-deploy-retrieve/pull/1404), plugin-deploy-retrieve PR [#1137](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1137)) * FIX: Support for 21 new (source-deploy-retrieve PR [#1398](https://github.com/forcedotcom/source-deploy-retrieve/pull/1398)) * AssessmentConfiguration * ContextUseCaseMapping * ContractType * DocumentTemplate * EmployeeDataSyncProfile * ExternalAuthIdentityProvider * ExternalDataTranObject * ExternalDocStorageConfig * GenAiPlugin * LearningAchievementConfig * MktDataConnection * MktDataConnectionSrcParam * PortalDelegablePermissionSet * ProductAttrDisplayConfig * ProductSpecificationRecType * ProductSpecificationType * RecAlrtDataSrcExpSetDef * ReferencedDashboard * RelatedRecordAssocCriteria * VirtualVisitConfig * WaveAnalyticAssetCollection ## 2.55.6 (August 21, 2024) * NEW: Execute a SOSL text-based search query in your org with the new `data search` command. Similar to how the `data query` command works with SOQL queries, you can specify the SOSL query at the command line with the `--query` flag or read the query from a file with the `--file` flag. This example executes the specified SOSL query in an org with alias `my-scratch`: ```bash sf data search --query "FIND {Anna Jones} IN Name Fields RETURNING Contact (Name, Phone)" --target-org my-scratch ``` (plugin-data PR [#1025](https://github.com/salesforcecli/plugin-data/pull/1025)) * FIX: When parsing a scratch org definition file, Salesforce CLI now removes the `$schema` property (if it exists at the top of the JSON file) to prevent getting an invalid JSON error. (sfdx-core PR [#1113](https://github.com/forcedotcom/sfdx-core/pull/1113)) Thank you, [Alan Jaouen](https://github.com/alanjaouen), for noticing the problem and then contributing the fix! We love it. * FIX: We now wait for config files to be unlocked before we read them. This improvement fixes issues like parallel command executions that cause file reads to return empty. (GitHub issue [#2965](https://github.com/forcedotcom/cli/issues/2965), sfdx-core PR [#1116](https://github.com/forcedotcom/sfdx-core/pull/1116)) * FIX: We updated the help and output of the `--package-name` flag of `project retrieve start` to clarify that the results are for reference only and shouldn't be used in your development work. (GitHub issue [#2931](https://github.com/forcedotcom/cli/issues/2931), plugin-deploy-retrieve [#1124](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1124)) * FIX: Salesforce DX projects now support the UiFormatSpecificationSet [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.54.6 (August 14, 2024) * NEW: Salesforce CLI now automatically regenerates the autocomplete cache after you install or uninstall a plugin to ensure that the autocomplete feature is always using the latest set of CLI command and flag names. (plugin-autocomplete PR [#753](https://github.com/oclif/plugin-autocomplete/pull/753), oclif plugin-plugins PR [#932](https://github.com/oclif/plugin-plugins/pull/932)) What's autocomplete, you ask? It's a way to automatically "complete" a partially-typed command or flag name by pressing the `` key when using Salesforce CLI at the terminal or command window. It's a super-useful feature, so check out [the documentation](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_autocomplete.htm) to learn how to configure and use it! * FIX: The `project deploy start` command now correctly handles deployments of changed custom fields, even when the parent object hasn't changed. (source-deploy-retrieve PR [#1375](https://github.com/forcedotcom/source-deploy-retrieve/pull/1375)) * FIX: The `project deploy start` command now correctly handles deployments of objects whose source files are spread across multiple folders in your project. (GitHub issue [#2230](https://github.com/forcedotcom/cli/issues/2230), source-deploy-retrieve PR [#1381](https://github.com/forcedotcom/source-deploy-retrieve/pull/1381)) * FIX: Salesforce CLI now constructs valid URLs when gathering results from an execution of the `data query --bulk --query ` command. (GitHub issue [#2968](https://github.com/forcedotcom/cli/issues/2968), jsforce PR [#1550](https://github.com/jsforce/jsforce/pull/1550)) ## 2.53.6 (August 7, 2024) * NEW: If you misspell a metadata type when using the `--metadata` flag of one of the `project` commands, such as `project deploy start`, we now prompt you with similar valid options. We also provide other troubleshooting resources. Go ahead, make a typo and see what the command suggests! (source-deploy-retrieve PR [#1374](https://github.com/forcedotcom/source-deploy-retrieve/pull/1374)) * NEW: Review what the `dev generate command|plugin` commands will do, without actually changing anything on your computer, with the new `--dry-run` flag. Instead, the command displays the files it will update or create and the commands it will run when you don't specify `--dry-run`. For example: ```bash $ sf dev generate command --name init --dry-run [DRY RUN] Updating package.json [DRY RUN] Creating src/commands/init.ts [DRY RUN] Creating messages/init.md [DRY RUN] Creating test/commands/init.nut.ts [DRY RUN] Creating test/commands/init.test.ts [DRY RUN] yarn format [DRY RUN] yarn lint -- --fix [DRY RUN] yarn compile ``` (plugin-dev PR [#519](https://github.com/salesforcecli/plugin-dev/pull/519)) * CHANGE: We've deprecated using the `--wait` flag of the `data query` command without `--bulk`. We plan to remove the usage in a future release. You can safely stop using `--wait` in this case, because it never affected the command without `--bulk` anyway. (plugin-data PR [#1002](https://github.com/salesforcecli/plugin-data/pull/1002)) * FIX: The `sf update` command now works correctly on computers running proxies. (plugin-update PR [#880](https://github.com/oclif/plugin-update/pull/880)) * FIX: If a flag value contains a comma in its name, you can now escape it with a `\` character so that Salesforce CLI doesn't think it's a delimiter. For example: `project source convert --source-dir dirwith\,comma`. Also, as part of this fix, we now print a warning when you use the old format of specifying multiple flag values with a comma (`--flag value1,value2`). Instead you should specify the flag multiple times (`--flag value1 --flag value2`). (GitHub issue [#2928]https://github.com/forcedotcom/cli/issues/2928), oclif PR [#1148](https://github.com/oclif/core/pull/1148)) ## 2.52.6 (July 31, 2024) * NEW: Salesforce CLI now supports the lowercase versions of the proxy environment variables: `http_proxy` and `https_proxy`. Lower-case env variables take precedence over their uppercase equivalents (`HTTP_PROXY` and `HTTPS_PROXY`). (jsforce PR [#1534](https://github.com/jsforce/jsforce/pull/1534)) * CHANGE: You're no longer required to run these commands inside of a Salesforce DX project: * `package installed list` * `package list` * `package1 version create` (GitHub discussion [#2932](https://github.com/forcedotcom/cli/discussions/2932), plugin-packaging PR [#733](https://github.com/salesforcecli/plugin-packaging/pull/733)) * CHANGE: The standard (non-JSON) output of the `org list metadata` and `org list metadata-types` commands are now in table format. (plugin-org PR [#1141](https://github.com/salesforcecli/plugin-org/pull/1141)) * FIX: The `project convert mdapi` command now correctly puts the converted files into the full `--output-dir` directory, if the flag is specified. (plugin-deploy-retrieve PR [#1091](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1091)) * FIX: Salesforce CLI now correctly accepts and prefers SF_AUDIENCE_URL (rather than SFDX_AUDIENCE_URL) and SF_DOMAIN_RETRY (rather than SFDX_DOMAIN_RETRY). (sfdx-core PR [#1104](https://github.com/forcedotcom/sfdx-core/pull/1104)) * FIX: We've improved the errors that result from certain executions of `project deploy` commands that are supposed to fail, such as executing `project deploy quick` and passing it an invalid job ID. (GitHub issue [#2962](https://github.com/forcedotcom/cli/issues/2962), sfdx-core PR [#1108](https://github.com/forcedotcom/sfdx-core/pull/1108)) * FIX: Let's say you have two sets of source files associated with two different objects in a package directory. Both sets of files also include the `All.listView-meta.xml` file and the ListView's XML is exactly the same. The [Source Mobility (beta)](./README.md#2448-jun-5-2024) feature now correctly detects that moving both sets of files to a new package directory isn't an actual source change that needs to be tracked. (GitHub issue [#2945](https://github.com/forcedotcom/cli/issues/2945), source-tracking PR [#631](https://github.com/forcedotcom/source-tracking/pull/631)) ## 2.51.6 (July 24, 2024) * CHANGE: We deprecated the CMTRecordManagedDeletion scratch org feature because it's no longer necessary. The scratch org feature allows you to remove custom metadata type records from a second-generation managed package. But as of the Spring '24 Salesforce release, the feature is now available to all independent software vendors (ISVs). See the [Spring '24 release notes](https://help.salesforce.com/s/articleView?id=release-notes.rn_packaging_remove_cmt_records.htm&release=248&type=5) for more information about the new feature. (sfdx-core PR [#1102](https://github.com/forcedotcom/sfdx-core/pull/1102)) * FIX: Deploying, retrieving, or converting projects that contain multiple custom label files no longer result in `JavaScript heap out of memory` errors. (GitHub issue [#2939](https://github.com/forcedotcom/cli/issues/2939), source-deploy-retrieve PR [#1368](https://github.com/forcedotcom/source-deploy-retrieve/pull/1368)) * FIX: We've improved the error message returned when `project deploy start --json` encounters a test failure as it's validating the deployment. ((GitHub issue [#2952](https://github.com/forcedotcom/cli/issues/2952), plugin-deploy-retrieve [#1085](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1085)) ## 2.50.6 (July 17, 2024) * NEW: By default, Salesforce CLI uses 128-bit encryption to encrypt its internal files, such as the authorization files associated with the orgs you’ve logged into. For increased security, you can now enable 256-bit encryption. Check out [these docs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_enable_256_bit_encryption.htm) for instructions. (GitHub issue [#1861](https://github.com/forcedotcom/cli/issues/1861), sfdx-core PR [#810](https://github.com/forcedotcom/sfdx-core/pull/810)) * FIX: Plugins (ex: sfdx-scanner) using an old version of our libraries would cause an error. We're now preventing that error. (GitHub issue [#2935](https://github.com/forcedotcom/cli/issues/2935), sfdx-core PR [#1098](https://github.com/forcedotcom/sfdx-core/pull/1098)) * FIX: `sf project deploy start` with `--coverage-formatters` now prints the correct location for the coverage files in its output. (GitHub issue [#2816](https://github.com/forcedotcom/cli/issues/2816), plugin-deploy-retrieve PR [#973](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/973)). We actually fixed this in April but forgot to put it in the release notes. * FIX: Recently created packages take some time to become available to all orgs. If you use `sf package install` to install that's not available yet, you get an error. The error now explains that it might work but not yet. (GitHub issue [#2921](https://github.com/forcedotcom/cli/issues/2921), packaging library PR [#600](https://github.com/forcedotcom/packaging/pull/600/)) ## 2.49.7 (July 10, 2024) * NEW and FIX: (This new and fixed issue is interesting mostly to Salesforce CLI plugin developers.) The JSDoc for the [`SfProject`](https://forcedotcom.github.io/sfdx-core/classes/sfProject.SfProject.html) and [`SfProjectJson`](https://forcedotcom.github.io/sfdx-core/classes/sfProject.SfProjectJson.html) classes in the `@salesforce/core` library now align with the code, and we cleaned up the examples. While we were messing around in there anyway, we added these two useful methods: `SfProject.getPluginConfiguration` and `SfProject.setPLuginConfiguration`. Check 'em out! (sfdx-core PR [#1094](https://github.com/forcedotcom/sfdx-core/pull/1094)) * CHANGE: After a [successful beta period](https://github.com/forcedotcom/cli/issues/2738), the `data import|export beta tree` commands are now generally available. Specifically: * We moved the new functionality in `data import beta tree` to the "official" `data import tree` command. We moved the functionality from the old `data import tree` to `data import legacy tree`. Similarly... * We moved the new functionality in `data export beta tree` to the "official" `data export tree` command. We moved the functionality from the old `data export tree` to `data export legacy tree`. What does this mean in practice? As of this release, when you execute `data import tree`, for example, you get the _new_ functionality that was in beta until now. If you run into any issues and you want to return to the old functionality, use the `data import legacy tree` command. Same with `data export tree`. However, note that we plan to remove these `legacy` commands in November, 2024. Read about the changes we added to these new commands, including two breaking changes to `data import tree`, in [this issue](https://github.com/forcedotcom/cli/issues/2738) that we've pinned since February 2024. (plugin-data PR [#975](https://github.com/salesforcecli/plugin-data/pull/975)). * CHANGE: These scratch org snapshot commands are now generally available; they were previously in beta. (plugin-signups PR [#629](https://github.com/salesforcecli/plugin-signups/pull/629)) * `org create snapshot` * `org delete snapshot` * `org get snapshot` * `org list snapshot` * FIX: You can now correctly deploy and retrieve the DecisionMatrixDefinition, DecisionMatrixDefinitionVersion, and ExpressionSetDefinitionVersion . (GitHub issue [#2823](https://github.com/forcedotcom/cli/issues/2823), source-deploy-retrieve PR [#1357](https://github.com/forcedotcom/source-deploy-retrieve/pull/1357)) * FIX: You can now correctly deploy and retrieve the ExperienceResource, DigitalExperienceBundle, and DigitalExperience . (GitHub issue [#2634](https://github.com/forcedotcom/cli/issues/2634), source-tracking PR [#621](https://github.com/forcedotcom/source-tracking/pull/621)) * FIX: You can now use the `--purge-on-delete` and `--metadata-dir` flags of the `project deploy start` command together to hard delete components whose local source files are in metadata-format. "Hard delete" means the component is immediately eligible for deletion in the org rather than being stored in the Recycle Bin. The directory pointed to by `--metadata-dir` must contain at least one of the destructive manifest files (`destructiveChangesPre.xml` or `destructiveChangesPost.xml`) or you get an error. (GitHub issue [#2909](https://github.com/forcedotcom/cli/issues/2909), plugin-deploy-retrieve [#1069](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1069)) * FIX: The `org list` command no longer displays incorrect information for a scratch org when its ID (when you ignore case) matches the ID of other ScratchOrgInfo records in the Dev Hub org. (plugin-org PR [#1119](https://github.com/salesforcecli/plugin-org/pull/1119)) * FIX: We improved the error message when a deploy, retrieve, or convert fails because of a problem with the source file, such as an incorrect XML element or missing parent XML file. (source-deploy-retrieve PR [#1355](https://github.com/forcedotcom/source-deploy-retrieve/pull/1355)) ## 2.48.6 (July 3, 2024) * NEW: Filter the list of package versions that are returned from the `package version list` command based on the source-control branch that the package versions are based on. (GitHub issue [#1530](https://github.com/forcedotcom/cli/issues/1530), plugin-packaging PR [#690](https://github.com/salesforcecli/plugin-packaging/pull/690), packaging PR [#594](https://github.com/forcedotcom/packaging/pull/594)) This example lists package versions that are based on the `featureA` branch in your default Dev Hub org: ``` sf package version list --branch featureA ``` * CHANGE: The colorization of the log output when you run `apex get log` and `apex tail log` is now the same; previously the commands used different color schemes, which was a tad confusing. (plugin-apex PR [#484](https://github.com/salesforcecli/plugin-apex/pull/484)) * CHANGE: The deprecation warning for the sfdx-style `force:org:create`, `force:org:delete`, `force:mdapi:*`, and `force:source:*` commands now include the date when they will be removed: November 6, 2024. (plugin-org PR [#1118](https://github.com/salesforcecli/plugin-org/pull/1118)) * CHANGE: You can now include keys that start with an upper-case letter inside of the `plugins` property of `sfdx-project.json` file. Almost all keys in the file must start with a lower-case letter (camelCase). We made this change because we previously made an exception for keys inside the `packageAlias` property, and sometimes it's useful to use these same key names in the `plugin` section too. We continue to enforce camelCase naming for all other `sfdx-project.json` keys. ([Trailblazer Community bug report](https://trailhead.salesforce.com/trailblazer-community/feed/0D53A00003wzhsn), sfdx-core PR [#1093](https://github.com/forcedotcom/sfdx-core/pull/1093)) * FIX: We fixed a bug where different major versions of sfdx-core in use simultaneously would cause a TypeError (github issue [#2935](https://github.com/forcedotcom/cli/issues/2935), sfdx-core PR [#1098](https://github.com/forcedotcom/sfdx-core/pull/1098)). * FIX: We fixed a bug in which the first install of a JIT plugin would sometimes fail with the error `ModuleLoadError: [MODULE_NOT_FOUND]`. (oclif PR [#1124](https://github.com/oclif/core/pull/1124)) * FIX: Salesforce CLI now correctly handles situations such as expired passwords or required multi-factor authentication when it detects that a session has expired. (jsforce issues [#1291](https://github.com/jsforce/jsforce/issues/1291), [#1308](https://github.com/jsforce/jsforce/issues/1308), and [#1411](https://github.com/jsforce/jsforce/issues/1411); sfdx-core PR [#1095](https://github.com/forcedotcom/sfdx-core/pull/1095), jsforce PR [#1517](https://github.com/jsforce/jsforce/pull/1517)) ## 2.47.6 (June 26, 2024) * NEW: Permanently delete records in your org via the Bulk API 2.0 with the new `--hard-delete` flag of the `data delete bulk` command. When you specify this flag, the records become immediately eligible for deletion, which means you no longer need to manually clean them from the Recycle Bin. For example, permanently delete account records from your default org using the IDs listed in the specified CSV file: ``` sf data delete bulk --sobject Account --file files/delete.csv --hard-delete ``` Users must have the "Bulk API Hard Delete" system permission to use the `--hard-delete` flag. This permission is disabled by default and can be enabled only by a system administrator. (GitHub discussion [#2904](https://github.com/forcedotcom/cli/discussions/2904), plugin-data PR [#959](https://github.com/salesforcecli/plugin-data/pull/959)) * FIX: The `force data bulk delete|status|upsert` commands now stop polling for the bulk job state in the org, and then stop executing and throw an error, if the job is aborted for some reason. These commands use Bulk API 1.0; the `data bulk` commands that use Bulk API 2.0 already work this way. (GitHub jsforce issue [#765](https://github.com/jsforce/jsforce/issues/765), jsforce PR [#1481](https://github.com/jsforce/jsforce/pull/1481)) * FIX: We've improved the warning message when retrieving custom fields using wildcards. (GitHub issue [#1366](https://github.com/forcedotcom/cli/issues/1366), plugin-deploy-retrieve [#1052](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1052)) * FIX: If a scratch org creation fails, after the org has created (such as it fails to deploy the settings), the command returns exit code 68 (like all other partial success outcomes). It will save the auth so you can debug the settings deploy error or delete the scratch org. (GitHub issue [#202](https://github.com/forcedotcom/cli/issues/202), sfdx-core [#1086](https://github.com/forcedotcom/sfdx-core/pull/1086)) * FIX: Salesforce DX projects now support the StageDefinition [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). Salesforce DX projects no longer support using the ExpressionSetDefinitionVersion metadata type directly. Use its parent (ExpressionSetDefinition) instead. ## 2.46.6 (June 19, 2024) * NEW: We now publish all artifacts associated with a Salesforce CLI release in the [salesforce/cli](https://github.com/salesforcecli/cli/releases) GitHub repository. The release artifacts include the operating system-specific installers, such as the Windows `*.exe` executable, and all TAR files for the Linux, Windows, and macOS installs. To download a particular artifact, go to the [Releases](https://github.com/salesforcecli/cli/releases) page, click on the release (such as [2.45.6](https://github.com/salesforcecli/cli/releases/tag/2.45.6)), open **Assets**, and then click on the artifact. (github-workflows PR [#107](https://github.com/salesforcecli/github-workflows/pull/107)) The links to download the Salesforce CLI installation packages, executables, and TAR files that are documented in the [Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm) continue to work as before. * NEW: Salesforce CLI now prompts you with potential alternatives when you misstype a username or alias when running an `org login` command. (sfdx-core PR [#1079](https://github.com/forcedotcom/sfdx-core/pull/1079)) * CHANGE: We've improved the filesystem structure of the output when you set the SF_MDAPI_TEMP_DIR environment variable and then run `project deploy start` or `project retrieve start`. These changes make it easier to debug any issues when deploying or retrieving. The changes to the output include: * A top-level directory whose name includes the timestamp of the operation and whether the output is a result of a deploy or a retrieve. * For retrieves, the output includes both formats of the retrieved files, in their own directories (`metadata` and `source`). The `metadata` directory includes the downloaded `.ZIP` file and the unzipped metadata format files; the `source` directory contains the converted files in source format. Both directories include the `package.xml` file. * For deploys, the output includes only the metadata format of the deployed files in the `metadata` directory, along with a `package.xml` file. (source-deploy-retrieve PR [#1331](https://github.com/forcedotcom/source-deploy-retrieve/pull/1331)) * FIX: Source Mobility (BETA): If you move a local file to a new location in your project, and then edit the file before running `project deploy start|preview` or `project retrieve start|preview`, Salesforce CLI now correctly handles both the file move and the update. (source-tracking [#601](https://github.com/forcedotcom/source-tracking/pull/601)) * FIX: Source Mobility (BETA): You can now move source files in very large projects (over 8GB with over 1700 files) and successfully deploy without getting an out of memory error. (GitHub issue [#2880](https://github.com/forcedotcom/cli/issues/2880), source-tracking PR [#591](https://github.com/forcedotcom/source-tracking/pull/591)) * FIX: When retrieving a CustomField from the org, `project retrieve start` now preserves the content of the field's CustomObject source file. We partly fixed this bug [back in May](./README.md#2418-may-15-2024), but this time around we think we fixed it all. (GitHub issue [#2865](https://github.com/forcedotcom/cli/issues/2865), source-deploy-retrieve PR [#1338](https://github.com/forcedotcom/source-deploy-retrieve/pull/1338)) ## 2.45.6 (June 12, 2024) * NEW: We now warn you if you set an alias that includes a space, which we don't recommend. If you decide to stick with the spaces, then you must use double quotes around it, such as: ```bash sf project deploy start --target-org "my scratch" ``` (plugin-settings PR [#625](https://github.com/salesforcecli/plugin-settings/pull/625)) * FIX: We now correctly display an error if you try to convert source files that are already in metadata format to the same format. (source-deploy-retrieve PR [#1329](https://github.com/forcedotcom/source-deploy-retrieve/pull/1329)) * FIX: The JSON response, when running the `org sandbox create|refresh|resume` commands with the `--json` flag, now includes the sandbox username if the sandbox is in a completed state and has been authenticated. This update makes the JSON output consistent with the human-readable output. (GitHub issue [#2879](https://github.com/forcedotcom/cli/issues/2879), plugin-org PR [#1068](https://github.com/salesforcecli/plugin-org/pull/1068)) * FIX: We improved the error message when you run `package install` on a package that was created with an installation key, but you either don't provide the key when installing it, or the key is incorrect. (GitHub issue [#2882](https://github.com/forcedotcom/cli/issues/2882), packaging PR [#580](https://github.com/forcedotcom/packaging/pull/580)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * EnblProgramTaskSubCategory * LearningItemType ## 2.44.8 (Jun 5, 2024) * NEW: (Beta) Enable a behavior of your project source files with the new `project convert source-behavior` command. For example, to update your project so it starts decomposing permission sets, run this command: ```bash $ sf project convert source-behavior --behavior decomposePermissionSetBeta ``` When the command finishes, your `sfdx-project.json` file is updated to always decompose permission sets, and the existing permission set files in your local package directories are converted into the new decomposed format. You run this command only once for a given behavior change. Use the `--dry-run` flag to preview what would be changed; sample files are created in a `DRY-RUN-RESULTS` directory. Here are the current possible values for the `--behavior` flag: * `decomposePermissionSetBeta` — Decompose the [PermissionSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm) metadata type. * `decomposeCustomLabelsBeta` — Decompose the [CustomLabels](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customlabels.htm) metadata type. * `decomposeWorkflowBeta` — Decompose the [WorkFlow](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_workflow.htm) metadata type. * `decomposeSharingRulesBeta` — Decompose the [SharingRules](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_sharingrules.htm) metadata type This command replaces the manual steps we documented in the [April 10, 2024](./README.md#2368-april-10-2024) release notes for converting your project to decompose the additional four metadata types. Because the behaviors are beta, the values for the `--behavior` flag include the word `Beta`. When a particular behavior becomes generally available (GA), we'll remove the `Beta` label; for example, when we make decomposing permission sets generally available, the new flag value will be `--behavior decomposePermissionSet`. This command, and the individual behaviors, can become generally available at different times; check these release notes for announcements. (plugin-deploy-retrieve PR [#1015](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/1015)) * NEW: We've improved the `doctor` command so it now checks whether your computer can access certain Web sites and registries required by Salesforce CLI. Here's truncated sample output to show which URLs it checks: ```bash $ sf doctor === Running all diagnostics pass - salesforcedx plugin not installed pass - no linked plugins pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org pass - [@salesforce/plugin-trust] can ping: https://registry.yarnpkg.com pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org/ pass - can access: https://test.salesforce.com pass - can access: https://appexchange.salesforce.com/services/data pass - can access: https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-win32-x64-buildmanifest ... ``` (plugin-info PR [#746](https://github.com/salesforcecli/plugin-info/pull/746), plugin-trust PR [#828](https://github.com/salesforcecli/plugin-trust/pull/828)) * NEW: Source Mobility (BETA). Source files can now be moved within your local Salesforce DX project without source-tracking thinking that you've deleted and then recreated a metadata component. This is a BETA feature and you must opt-in to enable it. You can opt-in by setting the SF_BETA_TRACK_FILE_MOVES environment variable to `true`. Then reorganize your files as you like! A few things to keep in mind: * Source Mobility works with file moves, not file renames. Renaming a source file is still interpreted as deleting a metadata component and creating a new one with the different name. * Child source files can only move to an identically named parent. For example, a custom field can move between Object folders in different package directories only if both Object folders have the same name. Enjoy! (GitHub discussion [#2682](https://github.com/forcedotcom/cli/discussions/2682), source-tracking [#574](https://github.com/forcedotcom/source-tracking/pull/574)) * NEW: Upload a local file to an org with the new `data create file` command. The default title of the uploaded file in the Salesforce UI is its filename; you can change its title with the `--title` flag. By default, the file isn't associated with a Salesforce record; use the `--parent-id` flag to attach the file to an existing Salesforce record, such as an account. In this example, the uploaded file is given a new title and it's attached to the Salesforce record with ID a03fakeLoJWPIA3: ```bash sf data create file --file resources/astro.png --parent-id a03fakeLoJWPIA3 --title AstroOnABoat --target-org my-sandbox ``` (GitHub issues [#2344](https://github.com/forcedotcom/cli/discussions/2344) and [#2346](https://github.com/forcedotcom/cli/discussions/2346), plugin-data PR [#922](https://github.com/salesforcecli/plugin-data/pull/922)) * CHANGE: We've changed the name of the new beta `sfdx-project.json` option that you use to decompose the optional metadata types when sync'ing source between your org and project. * Old name: `registryPresets` * New name: `sourceBehaviorOptions` For example: ```bash "sourceBehaviorOptions": ["decomposePermissionSetBeta", "decomposeWorkflowBeta"] ``` The new beta feature itself hasn't changed, including the list of possible values for the `sourceBehaviorOptions`. See the [April 10, 2024 release notes](./README.md#2368-april-10-2024) for more information. (schemas PR [#87](https://github.com/forcedotcom/schemas/pull/87), source-deploy-retrieve PR [#1312](https://github.com/forcedotcom/source-deploy-retrieve/pull/1312)) * FIX: If you delete a Global Action in a source-tracking-enabled org, then run `project retrieve start`, Salesforce CLI now deletes it locally. Previously it did nothing because the server incorrectly lists the change as `QuickActionDefinition`. (GitHub issue [#2829](https://github.com/forcedotcom/cli/issues/2829), source-tracking PR [#590](https://github.com/forcedotcom/source-tracking/pull/590)) * FIX: The `project deploy report` command no longer displays incorrect warnings about source format files that don't apply to the asynchronous deployment of metadata format files. (GitHub issue [#2862](https://github.com/forcedotcom/cli/issues/2862), source-deploy-retrieve PR [#1311](https://github.com/forcedotcom/source-deploy-retrieve/pull/1311)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * GenAiFunction * GenAiPlanner * DataKitObjectDependency ## 2.42.6 (May 22, 2024) * NEW: Quickly find the date that your current Salesforce CLI version was published by running the `version --verbose` command. The new output also lists the current `latest` (AKA `stable`) version of Salesforce CLI, based on the [npm tags](https://www.npmjs.com/package/@salesforce/cli?activeTab=versions). The new output also displays the same information for any user-installed plugins, including the Salesforce JIT plugins such as `@salesforce/sfdx-scanner`. We also made the output easier to read. (oclif plugin-version PR [#425](https://github.com/oclif/plugin-version/pull/425)) Here's partial output of the new command showing that the installed version (`2.39.6`) was published 21 days ago, and that the latest version is `2.40.7`: ```bash $ sf version --verbose CLI Version: @salesforce/cli/2.39.6 published 21 days ago (Tue Apr 23 2024) (latest is 2.40.7) ... ``` * CHANGE: If you install Salesforce CLI using `npm`, your local version of Node.js must be at least 18.16. (cli PR [#1645](https://github.com/salesforcecli/cli/pull/1645)) * FIX: On Windows, running a Salesforce CLI command no longer causes a new CMD window to briefly appear and then disappear. Thanks [@jaklein](https://github.com/jaklein) for pointing out the fix! (GitHub issue [#2833](https://github.com/forcedotcom/cli/issues/2833), plugin-telemetry PR [#620](https://github.com/salesforcecli/plugin-telemetry/pull/620)) * FIX: (This fix is mostly relevant to our fabulous plugin developers) We've updated various files, such as the schema for `sfdx-project.json`, so that you no longer get type issues or `Property not found` when developing with our APIs in VSCode or other IDE. (GitHub issue [#2201](https://github.com/forcedotcom/cli/issues/2201), schemas PR [#85](https://github.com/forcedotcom/schemas/pull/85), sfdx-core [#1066](https://github.com/forcedotcom/sfdx-core/pull/1066), packaging [#569](https://github.com/forcedotcom/packaging/pull/569)) ## 2.41.8 (May 15, 2024) * NEW: The `project retrieve start` command now warns you if you have the pattern `**/unpackaged/**` in your `.forceignore` file. This pattern causes the retrieve to ignore all files, because `/unpackaged` is the directory within the retrieved ZIP file in which all unpackaged metadata lives. (GitHub issue [#2399](https://github.com/forcedotcom/cli/issues/2399), source-deploy-retrieve PR [#1301](https://github.com/forcedotcom/source-deploy-retrieve/pull/1301)) * CHANGE: The `org delete snapshot` command now prompts for confirmation from the user before it deletes the snapshot; previously the command didn't prompt. Use the new `--no-prompt` flag to not be prompted, which is the old behavior. (plugin-signups PR [#567](https://github.com/salesforcecli/plugin-signups/pull/567)) * FIX: Specifying the `--no-namespace` flag of the `org create scratch` command now correctly creates a scratch org that doesn't have a namespace. (GitHub issue [#2855](https://github.com/forcedotcom/cli/issues/2855), sfdx-core PR [#1064](https://github.com/forcedotcom/sfdx-core/pull/1064)) * FIX: When retrieving a CustomField from the org, `project retrieve start` now preserves the content of the field's CustomObject source file. (GitHub issue [#2865](https://github.com/forcedotcom/cli/issues/2865), source-deploy-retrieve PR [#1308](https://github.com/forcedotcom/source-deploy-retrieve/pull/1308)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * ForecastingGroup * RecordAlertTemplate * RetrievalSummaryDefinition * SearchCustomization * SearchOrgWideObjectConfig ## 2.40.7 (May 8, 2024) * NEW: Some Salesforce CLI downloads, installations, and updates are now faster because we reduced the size of the Salesforce CLI OS-specific installers and TAR files. Specifically, we no longer include files like `oclif.lock`, `yarn.lock`, `npm-shrinkwrap`, and `package-lock` in them. (GitHub discussion [#2835](https://github.com/forcedotcom/cli/discussions/2835), oclif PR [#1385](https://github.com/oclif/oclif/pull/1385)) * FIX: When converting from mdapi format to source format, Salesforce CLI now preserves all comments in the metadata XML file. As a result, the help text, labels, and picklist values of Custom Object Translations are correctly included in the source format files. (GitHub issue [#2830](https://github.com/forcedotcom/cli/issues/2830), source-deploy-retrieve PR [#1288](https://github.com/forcedotcom/source-deploy-retrieve/pull/1288)) * FIX: Salesforce CLI once again supports big object types whose index files use the legacy `.indexe` suffix rather than the better `.index` suffix. But we've also added a warning if your big object uses the `.indexe` suffix, asking you to update it to `.index`. (GitHub issue [#2847](https://github.com/forcedotcom/cli/issues/2847), source-deploy-retrieve PR [#1298](https://github.com/forcedotcom/source-deploy-retrieve/pull/1298)) * FIX: The `.forceignore` file now works consistently, whether you're using source or mdapi format. Specifically, when you deploy or retrieve in source format (using `sf project deploy start`, for example), the command respects file names of `.forceignore` entries in source format. Similarly, when you deploy or retrieve in mdapi format (using `sf project deploy start --metadata-dir`, for example), the command respects file name entries in mdapi format. (GitHub issue [#2737](https://github.com/forcedotcom/cli/issues/2737), source-deploy-retrieve PR [#1295](https://github.com/forcedotcom/source-deploy-retrieve/pull/1295)) * FIX: The `org shape list` command now works as expected, even when the connection to the Dev Hub org is incorrect. ## 2.39.6 (May 1, 2024) * FIX: `project delete source` doesn't throw errors when confirming that you want to delete source that doesn't exist locally. (GitHub issue [#2836](https://github.com/forcedotcom/cli/issues/2836), plugin-deploy-retrieve PR [#986](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/986)) * FIX: `project generate manifest --from-org` was throwing errors when the metadata API responds with metadata missing required properties. We've alerted the resonsible team, and in the meantime created some checks in the CLI to prevent the error (and warn you about what metadata can't be processed). (GitHub issue [2841](https://github.com/forcedotcom/cli/issues/2841), source-deploy-retrieve PR [#1296](https://github.com/forcedotcom/source-deploy-retrieve/pull/1296)). * FIX: `sf plugins link` had a problem linking plugins that needed to be compiled before use. We've fixed that (GitHub issue [#2818](https://github.com/forcedotcom/cli/issues/2818), oclif/plugin-plugins PR [#841](https://github.com/oclif/plugin-plugins/pull/841)) * FIX: `sf apex test run` handles the `--wait` flag better. (GitHub issue [#2108](https://github.com/forcedotcom/cli/issues/2108), plugin-apex PR [#422](https://github.com/salesforcecli/plugin-apex/pull/422), apex library PR [#364](https://github.com/forcedotcom/salesforcedx-apex/pull/364)) ## 2.38.7 (April 24, 2024) * NEW: Salesforce CLI downloads, installations, and updates just got a whole lot faster, especially on Windows! Why? Because we've significantly reduced the size of both the `npm` packages and the OS-specific installers. The `npm` reduction is the champion: it's ~35% smaller. But the installers are ~10% slimmer too. Nice. * NEW: You can now use the `language` property in scratch org definition files in combination with scratch org snapshots in Summer24. (GitHub issue [#2643](https://github.com/forcedotcom/cli/issues/2643), sfdx-core PR [#1055](https://github.com/forcedotcom/sfdx-core/pull/1055) plus some server-side changes in the major release) * FIX: Salesforce CLI, when interacting with an org, now properly retries the command when it runs into a network error. (GitHub issues [#1350](https://github.com/forcedotcom/cli/issues/1350) and [#2557](https://github.com/forcedotcom/cli/issues/2557), jsforce PR [#1403](https://github.com/jsforce/jsforce/pull/1403)) * FIX: The `project deploy report` command now returns results about all deployed files, even if they don't currently exist in your local project. This scenario can happen if the deploy occurs on one computer and the report command is run on a different computer where the project looks different. The report command warns the user if a local file doesnt' exist. (GitHub issues [#2602](https://github.com/forcedotcom/cli/issues/2603) and [#2602](https://github.com/forcedotcom/cli/issues/2602), source-deploy-retrieve PR [#1273](https://github.com/forcedotcom/source-deploy-retrieve/pull/1273)) * FIX: The `project deploy retrieve` command now does not check for a project when doing a metadata api retrieve when using the `--manifest` flag, and it shouldn't have started doing that. (GitHub issue [#2832](https://github.com/forcedotcom/cli/issues/2832) and [#2831](https://github.com/forcedotcom/cli/issues/2831), plugin-deploy-retrieve PR [#978](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/978) * FIX: NodeJS made a breaking windows-related security change. We adjusted the CLI to comply. (GitHub issue [#2822](https://github.com/forcedotcom/cli/issues/2822), plugin-telemetry PR [#611](https://github.com/salesforcecli/plugin-telemetry/pull/611), oclif/plugin-plugins PR [#847](https://github.com/oclif/plugin-plugins/pull/847), oclif/plugin-update [#788](https://github.com/oclif/plugin-update/pull/788)) NOTE: As a result of this NodeJS change, some windows users will see a terminal "flash" (see [#2833](https://github.com/forcedotcom/cli/issues/2833)) in certain scenarios. We're working on a way to avoid that. ## 2.37.4 (April 17, 2024) * NEW: The JSON output of the `package version create` command now contains more information: the percentage of Apex code lines that are covered by tests (CodeCoverage) and the full package version number (VersionNumber). The new CodeCoverage key corresponds to the Tooling API `Package2Version.CodeCoverage` field; the VersionNumber key corresponds to a concatenation of the `Package2Version.MajorVersion`, `Package2Version.MinorVersion`, `Package2Version.PatchVersion`, and `Package2Version.BuildNumber` fields. (packaging PR [#492](https://github.com/forcedotcom/packaging/pull/492)) Thank you, [Ronny Rokitta](https://github.com/Rocko1204)! This is a great follow-on contribution from the one you made in [January](./README.md#2257-jan-24-2024) -- we love repeat contributors. Cheers! * CHANGE: We removed the `force org clone` and `force org status` commands from Salesforce CLI; use the `org create sandbox` and `org resume sandbox`, respectively, instead. We deprecated the two commands on [Feb 9, 2023](https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md#71871-feb-9-2023). (plugin-org PR [#1009](https://github.com/salesforcecli/plugin-org/pull/1009)). * FIX: If you deploy source to an org, and source tracking fails for some reason (such as a server error, CLI error, or a problem in your environment), you now get the full details of the failure. Previously you would get just the `MetadataTransferError` error, and no more information, so it was difficult to troubleshoot what the problem was. (source-deploy-retrieve PR [#1275](https://github.com/forcedotcom/source-deploy-retrieve/pull/1275)) * FIX: You can now successfully run `project deploy report` and get information about a deployment that you first validated with `project deploy validate` and then quick deployed with `project deploy quick`. (plugin-deploy-retrieve PR [#962](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/962)) ## 2.36.8 (April 10, 2024) * NEW: (Beta) Specify that Salesforce CLI decompose four more metadata types when it converts from mdapi to source format, in addition to the types it currently decomposes automatically (CustomObject and CustomObjectTranslation). And stay tuned, we're planning to do more types soon! By "decompose" we mean that Salesforce CLI breaks the single, and often very large, mdapi-format XML file that corresponds to a metadata component into smaller XML files based on the sub-types. These files live in sub-directories of a directory named the same as the component. See [Salesforce DX Project Structure and Source Format](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm) for information on how CustomObject and CustomObjectTranslations are decomposed; that topic will soon be updated with similar information about the new decomposed types. Unlike CustomObject and CustomObjectTranslation, you must explicitly opt-in to decompose these new types. It's easy: just add a `registryPresets` option to your `sfdx-project.json` file and set it to one or more of these values: * `decomposePermissionSetBeta` : decompose the [PermissionSet](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm) metadata type * `decomposeWorkflowBeta` : decompose the [Workflow](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_workflow.htm) metadata type * `decomposeCustomLabelsBeta` : decompose the [CustomLabels](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_customlabels.htm) metadata type * `decomposeSharingRulesBeta` : decompose the [SharingRules](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_sharingrules.htm) metadata type When you next retrieve the component, it will be decomposed. (The values include the word `Beta`, because this feature is currently in beta. When it becomes generally available, you'll simply remove the `Beta` part.) For example, if you want to decompose PermissionSet and Workflow types, add this to your `sfdx-project.json`: `"registryPresets": ["decomposePermissionSetBeta", "decomposeWorkflowBeta"]` If you already have these metadata types in your project, be sure you follow these steps to start using this new feature: 1. Remove all the files that correspond to the existing metadata components from your project. For example, if you want to start decomposing PermissionSet and Workflow types, remove files that look something like this: ```bash cd rm force-app/main/default/permissionsets/MyPermSet.permissionset-meta.xml rm force-app/main/default/workflows/Account.workflow-meta.xml ``` 1. Update your `sfdx-project.json` file and specify the two values to the `registryPresets` option: `"registryPresets": ["decomposePermissionSetBeta", "decomposeWorkflowBeta"]` 1. Retrieve these components again: `sf project retrieve start --metadata PermissionSet --metadata Workflow` The command retrieved a bunch of smaller XML files for each permission set and workflow, rather than a single file. Hurray! (GitHub discussion [#2544](https://github.com/forcedotcom/cli/discussions/2544), issues [#1159](https://github.com/forcedotcom/cli/issues/1159), [#2356](https://github.com/forcedotcom/cli/discussions/2356), and [#2376](https://github.com/forcedotcom/cli/discussions/2376). source-deploy-retrieve PR [#1217](https://github.com/forcedotcom/source-deploy-retrieve/pull/1217) source-tracking PR [#552](https://github.com/forcedotcom/source-tracking/pull/552)) **NOTE**: _This feature is a Beta Service. Customers may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms (https://www.salesforce.com/company/legal/agreements/)._ **NOTE**: _This beta feature is supported and tested for only the `sf project deploy|retrieve|delete|convert` commands. We don't support using the `force:source:push|pull|deploy|retrieve` commands with this feature._ * NEW: Bypass the warning prompt that's displayed when you install a trusted, yet unsigned, plugin using its GitHub URL by adding the URL to the [Salesforce CLI allowlist](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_allowlist.htm). Previously you could add only npm names to the file. The GitHub URL must be in the format `https://github.com//`. For example, let's say you add the `https://github.com/oclif/plugin-version` plugin, which isn't signed by Salesforce, to the `unsignedPluginAllowList.json` file. You can then run this command and you won't get the warning prompt: ```bash sf plugins install https://github.com/oclif/plugin-version ``` We also improved the warning and install messages to clearly indicate which plugin you're installing. (plugin-trust PR [#771](https://github.com/salesforcecli/plugin-trust/pull/771)) * FIX: Salesforce DX projects now support the AffinityScoreDefinition [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.35.6 (April 3, 2024) * NEW: Specify the flag values for Salesforce CLI commands in local text files by using the `--flags-dir ` flag when running the command. If the command finds a file in the specified directory with the same name as one of its flags, it uses the contents of the file as the value of the flag. Take this command, for example: ```bash sf project deploy start --metadata ApexClass --test-level RunLocalTests --target-org my-scratch ``` Let's say you create a directory called `flag-values` in your DX project. You then create a file in that directory called `metadata` (no extension) and add one line of content to the file: `ApexClass`. Similarly, you create a file called `test-level` with contents `RunLocalTests` and a file called `target-org` with contents `my-scratch`. You can then run the preceding command from the DX project this way: ```bash sf project deploy start --flags-dir ./flag-values ``` Additional usage notes: * The files that contain flag values don't usually have an extension; the only exception is if the files contain `JSON` content, in which case you must use the `.json` extension, such as `files.json`. * For Boolean flags, create an empty file with the name of the Boolean flag. For example, to specify the `--concise` flag, create an empty file called `concise`. * You can name files for Boolean flags `no-`, as long as the Boolean flag supports it. For example, to use this feature with the `org create scratch` command and disable source tracking, create an empty file called `no-track-source`. * If you include multiple lines in a file, then the result is multiple flags, such as `--metadata ApexClass --metadata CustomObject --metadata PermissionSet`. * Actual flags take precedence over values in a file. For example, if you specify `--target-org my-scratch` when you run the command, but also specify `--flags-dir` that points to a `target-org` file that contains the line `my-other-scratch`, the command connects to `my-scratch`. The only exception is for flags that take multiple values, such as `--metadata`; in this case, the flag and file values are combined. * You can name the files using the flag's short name, such as `m` rather than `metadata`. * This release adds the new `--flags-dir` flag to all CLI commands except for the commands contained in these plugins: * [`sfdx-scanner`](https://github.com/forcedotcom/sfdx-scanner): Code Analyzer commands, such as `scanner run`. * [`plugin-devops-center`](https://github.com/salesforcecli/plugin-devops-center): DevOps Center commands, such as `project deploy pipeline start`. * [`plugin-functions`](https://github.com/salesforcecli/plugin-functions): Salesforce Functions commands, such as `run function`. Pretty cool feature, don't you think? (GitHub discussions [#2346](https://github.com/forcedotcom/cli/discussions/2346) and [#2670](https://github.com/forcedotcom/cli/discussions/2670). GitHub issue [#2260](https://github.com/forcedotcom/cli/discussions/2260). salesforcecli/cli PR [#1536](https://github.com/salesforcecli/cli/pull/1536), * CHANGE: As [previously announced](https://github.com/forcedotcom/cli/issues/2691), Salesforce CLI is now using a major new version of [`oclif/plugin-plugins`](https://github.com/oclif/plugin-plugins); this oclif plugin uses `npm` instead of `yarn` (v1) to install and update user plugins. In most cases, there's nothing for you to do as a result of this change. The user plugins you've already installed will continue to work and be updatable using `plugins update`. But just in case, check the **What do I need to do?** section of the [announcement](https://github.com/forcedotcom/cli/issues/2691) for the specific use cases in which you might need to do something. The announcement also explains why we made this change. If you experience issues after you update to this Salesforce CLI release, we recommend that you run `plugins reset --reinstall --hard`, which completely uninstalls all your plugins and then reinstalls them on your behalf. If you continue to experience issues, create a new GitHub issue. (oclif/plugin-plugins PR [#776](https://github.com/oclif/plugin-plugins/pull/776)) * FIX: You can now include the same source component in all the manifest files (standard, pre-deploy-delete, post-deploy-delete) simultaneously. As a result, you can now, for example, first delete a component and then add it again in a single execution of the `project deploy start` command. (GitHub issue [#2761](https://github.com/forcedotcom/cli/issues/2761), source-deploy-retrieve PR [#1261](https://github.com/forcedotcom/source-deploy-retrieve/pull/1261)) * FIX: Salesforce CLI now supports authenticating to orgs with `.cn` domains. (plugin-auth PR [#995](https://github.com/salesforcecli/plugin-auth/pull/955)) * FIX: You can now use the `--target-org` flag with the `project deploy cancel` command. (GitHub discussion [#2300](https://github.com/forcedotcom/cli/discussions/2300#discussioncomment-8053672), plugin-deploy-retrieve PR [#945](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/945)) * FIX: If you run a non-existent command with "closed stdin" (i.e. you specify `<&-` or `< /dev/null` after the command), Salesforce CLI now waits 10 seconds after prompting for a matching command, and then returns the appropriate error exit code. Previously it returned a `0` exit code. [oclif GitHub issue [#266](https://github.com/oclif/plugin-not-found/issues/266), oclif plugin-not-found PR [#566](https://github.com/oclif/plugin-not-found/pull/566)) * FIX: We've improved the performance and output messages for many of the `data` commands. In particular: * Improved the performance and reduced the API call usage when monitoring bulk jobs for these commands: `data delete bulk`, `data upsert bulk`, `data delete resume`, `data upsert resume`, `data query`. * Improved the error if you pass an unparseable CSV file to these commands: `data delete bulk`, `data upsert bulk`. * Improved the output of the bulk job event updates for these commands: `data delete bulk`, `data upsert bulk`, `data delete resume`, `data upsert resume`. (plugin-data PR [#843](https://github.com/salesforcecli/plugin-data/pull/843)) ## 2.34.7 (March 27, 2024) * CHANGE: You can now override the name or license type of a new sandbox (that you create with a definition file) by specifying the `--name` or `--license-type` flags in addition to `--definition-file`. Previously, if you specified a definition file, you couldn't also specify either `--name` or `--license-type`. For example, let's say the `sandboxName` option in the `config/dev-sandbox-def.json` file is `fulldev1`; the following command creates a sandbox using all the options in the definition file, except that the sandbox name is `fulldev2`: ```bash $ sf org create sandbox --definition-file config/dev-sandbox-def.json --target-org prodOrg --name fulldev2 ``` (plugin-org PR [#991](https://github.com/salesforcecli/plugin-org/pull/991)) * FIX: You can now successfully authorize an org using `org login web` and version 123 of the Chrome browser, which was recently released. (GitHub issue [#2785](https://github.com/forcedotcom/cli/issues/2785), sfdx-core PR [#1040](https://github.com/forcedotcom/sfdx-core/pull/1040), plugin-auth PR [#975](https://github.com/salesforcecli/plugin-auth/pull/975)) * FIX: String replacements during deployments of individual CustomLabel metadata types (without their parent CustomLabels metadata type) are now working as expected. (GitHub issue [#2755](https://github.com/forcedotcom/cli/issues/2755), source-deploy-retrieve PR [#1257](https://github.com/forcedotcom/source-deploy-retrieve/pull/1257)) * FIX: You can now successfully execute the `sf org open` command from the terminal window of VS Code that's running on Windows Subsystem for Linux (WSL) 2. (GitHub issue [#2677](https://github.com/forcedotcom/cli/issues/2677), plugin-org PR [#962](https://github.com/salesforcecli/plugin-org/pull/962)) Thank you [nrakuyama](https://github.com/nrakuyama) for contributing the fix! We love your initiative and help. Here's to many more! * FIX: We've improved how Salesforce CLI internally converts files between source and metadata formats. The conversion no longer returns an error when done outside a Salesforce DX project. Also, the conversion can now write a zip to disk. (source-deploy-retrieve PR [#1252](https://github.com/forcedotcom/source-deploy-retrieve/pull/1252)) Many thanks to [Aaron Csetter](https://github.com/aaron-csetter) for finding the problems, and then contributing the fixes. Contributions like yours help make Salesforce CLI a better-than-ever developer tool, and we're very appreciative! * FIX: When deploying, Salesforce CLI now continues to poll for status even when these HTTP error codes are in the response: 502, 503, and 420. (source-deploy-retrieve PR [#1262](https://github.com/forcedotcom/source-deploy-retrieve/pull/1262)) * FIX: Salesforce DX projects now support the ConversationMessageDefinition [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.33.3 (March 20, 2024) * FIX: The `org user display` command no longer displays the Profile Name twice. (GitHub issue [#2762](https://github.com/forcedotcom/cli/issues/2762), plugin-user PR [#898](https://github.com/salesforcecli/plugin-user/pull/898)) Thank you [dwbuttler](https://github.com/dwbuttler) for noticing the problem, reporting the issue, and then simply fixing it yourself. We love your initiative! And we look forward to more contributions from you and our fabulous community. * FIX: We've improved the error message returned when `project deploy validate --json` encounters a validation error with one or more metadata components. (GitHub issue [#2757](https://github.com/forcedotcom/cli/issues/2757), plugin-deploy-retrieve PR [#938](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/938)) * FIX: You can now successfully authenticate an org in which PKCE ([Proof Key for Code Exchange](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_pkce.htm&type=5)) is enforced. (GitHub Discussion [#2726](https://github.com/forcedotcom/cli/discussions/2726), sfdx-core PR [#1035](https://github.com/forcedotcom/sfdx-core/pull/1035)) ## 2.32.8 (March 13, 2024) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * MlModelArtifact * MlModelConnection * MlModelSchema ## 2.31.8 (March 8, 2024) * NEW: Hold on to your hats, folks -- you can now easily refresh a sandbox org with the new `org refresh sandbox` command. Refreshing a sandbox copies the metadata, and optionally data, from your production org to the refreshed sandbox org. Specify the sandbox you want to refresh with the --name flag and the production org that contains the sandbox licenses with the --target-org flag. You can optionally specify a [definition file](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_sandbox_definition.htm) with the --definition-file flag if you want to change the configuration of the refreshed sandbox, such as its license type or template ID. This example shows how to refresh a sandbox named "devSbx1" without changing its configuration. The production org that contains the sandbox license has the alias "prodOrg". ```bash sf org refresh sandbox --name devSbx1 --target-org prodOrg ``` In this example, your default org is also your production org with the sandbox licenses, so you don't need to specify --target-org. The configuration changes are in the specified definition file. ```bash sf org refresh sandbox --name devSbx2 --definition-file config/devSbx2-config.json ``` You can't change the sandbox name when you refresh it with this command. If you want to change the sandbox name, first delete it with the `org delete sandbox` command. And then recreate it with `org create sandbox` and give it a new name. (GitHub discussion [#2511](https://github.com/forcedotcom/cli/discussions/2511), plugin-org PR [#973](https://github.com/salesforcecli/plugin-org/pull/973), sfdx-core PR [#1031](https://github.com/forcedotcom/sfdx-core/pull/1031)) * FIX: Salesforce CLI no longer prompts and waits for an answer, and then time out and return a non-zero exit code, when you run a command that asks a question in a non-TTY environment. (GitHub issue [#2739](https://github.com/forcedotcom/cli/issues/2739), oclif/core PR [#967](https://github.com/oclif/core/pull/967)) * FIX: You can now correctly assign multiple permission set licenses at once with the `org assign permsetlicense` command by specifying multiple instances of the `--name` flag. While fixing this issue, we cleaned up a few other error-related issues. (GitHub issue [#2744](https://github.com/forcedotcom/cli/issues/2744), plugin-user PR [#877](https://github.com/salesforcecli/plugin-user/pull/877)) * FIX: Salesforce DX projects now support the EnablementProgramDefinition [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.30.8 (Feb 28, 2024) * CHANGE: We made a bunch of improvements to the `data import tree` and `data export tree` commands. But because these improvements introduce breaking changes, we're going to first beta the new functionality, and then make it generally available when we're sure everything is in tip-top shape. Here's an overview of the plan, but see the [pinned issue #2738](https://github.com/forcedotcom/cli/issues/2738) for details about the improvements, the breaking changes, and timeline. * This release contains two new commands with the improvements: `data import beta tree` and `data export beta tree`. The existing `data import tree` and `data export tree` commands continue to work as before and coexist with the new beta commands. * Test these beta commands and let us know if you find any issues. Also let us know if you like the improvements! * When the beta period is over, we'll move the functionality that we added to `data import|export beta tree` to the "official" `data import|export tree` commands. We'll then move the functionality in the _old_ `data import|export tree` commands to new commands called `data import|export legacy tree`. Enjoy! (GitHub issues [#2663](https://github.com/forcedotcom/cli/issues/2663) and [#248](https://github.com/forcedotcom/cli/issues/248). GitHub discussion [#2359](https://github.com/forcedotcom/cli/discussions/2359). plugin-data PR [#821](https://github.com/salesforcecli/plugin-data/pull/821) and [#810](https://github.com/salesforcecli/plugin-data/pull/810)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * OauthTokenExchangeHandler (GitHub discussion [#2736](https://github.com/forcedotcom/cli/discussions/2736)) * ActionableEventOrchDef * ActionableEventTypeDef * OmniExtTrackingDef * FIX: When you pass a command alias to `sf which`, it now outputs an `aliasOf` property that shows the command that the passed-in command is an alias of. (oclif GitHub issue [#515](https://github.com/oclif/plugin-which/issues/515), plugin-which PR [#545](https://github.com/oclif/plugin-which/pull/545)) ## 2.29.5 (Feb 21, 2024) * CHANGE: We removed the `--target-dev-hub` flag from these commands; the flag has been deprecated and hidden for over two years because it has no effect: * `org create user` * `org display user` * `org list users` (plugin-users PR [#864](https://github.com/salesforcecli/plugin-user/pull/864)) * FIX: We updated our GitHub Actions to be more friendly to external developers. In particular, we modified our [external plugin template](https://github.com/salesforcecli/plugin-template-sf-external) so that `dev generate plugin` generates updated sample GitHub Actions workflow files. We also added Personal Access Token instructions to the [README](https://github.com/salesforcecli/github-workflows) in our GitHub Actions repo. * FIX: Salesforce DX projects now support the EnablementMeasureDefinition [metadata type](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json). ## 2.28.6 (Feb 14, 2024) * NEW: Your work life is about to get more colorful with Salesforce CLI's new help themes. The help output now uses colors to highlight certain parts, such as the help sections (USAGE, FLAGS, DESCRIPTION, and so on), flags and their descriptions, executable name, and more. To see the default colors, run any command with `--help`- or `-h`. If you don't like the colors we chose, specify your own colors by creating a file called `theme.json` file in this location: * (Linux and macOS): `$HOME/.config/sf/theme.json` * (Windows) Depending on your configuration, either `C:\Users\\.config\sf\theme.json` or `%LOCALAPPDATA%\sf\theme.json` Use these JSON keys to specify the color of various sections. * `alias`: The aliases listed in the ALIASES section. * `bin`: The `sf` executable. * `command`: The command's name. * `commandSummary`: The command's summary. * `dollarSign`: The `$` printed before examples and usage. * `flag`: The flag long and short names. * `flagDefaultValue`: The text `[default: X]` shown for flags that have a default value. * `flagOptions`: The valid options for a flag. * `flagRequired`: The text `(required)` shown for required flags. * `flagSeparator`: The `,` that separates the short and long flag names (for example, `-f, --foo`). * `sectionDescription`: The text inside each section (for example, everything under the DESCRIPTION section). * `sectionHeader`: The section header (for example, DESCRIPTION). * `topic`: The topics listed in the TOPICS section. * `version`: The VERSION section shown when you run `sf --help`. For the key's value, use [chalk-style colors](https://github.com/chalk/chalk/?tab=readme-ov-file#colors) (such as `greenBright`), hex code (`#FF0000`) or RGB (`rgb(255,255,255)`). To _not_ colorize a section, set it to `none` or remove it from the `theme.json` file. As an example, here's the default `theme.json` file; it uses chalk-style colors. ```json { "aliases": "none", "bin": "blueBright", "command": "blueBright", "commandSummary": "none", "dollarSign": "green", "flag": "green", "flagDefaultValue": "blueBright", "flagOptions": "blueBright", "flagRequired": "red", "flagSeparator": "none", "sectionDescription": "none", "sectionHeader": "blue", "topic": "blueBright", "version": "none" } ``` Many thanks to [Alan Oricil](https://github.com/AllanOricil), who contributed the general themes feature to [`oclif`](https://github.com/oclif/core/pull/852). We thought it was very cool, so decided to implement it in Salesforce CLI. May the pretty colors bring a little spark of joy to our community! (salesforce/cli PR [#1451](https://github.com/salesforcecli/cli/pull/1451)) * NEW: It's now super-easy to get your Salesforce CLI installation into a "clean" state with the new `--reinstall` and `--hard` flags of `plugins reset`. * `--reinstall` does exactly what it says: reinstalls every plugin that you previously installed. * `--hard` removes all package manager related files and directories (`node_modules`, `package.json`, `yarn.lock`, `package-lock.json`) from Salesforce CLI's internal data directory. For example: ```bash sf plugins reset --reinstall --hard ``` (oclif/plugin-plugins PR [#777](https://github.com/oclif/plugin-plugins/pull/777)) * CHANGE: Any [string replacements](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_string_replace.htm) configured in your `sfdx-project.json` file are now also applied to source files that are packaged with the `package version create` command. The documentation will be updated shortly to reflect this change. (plugin-packaging PR [#566](https://github.com/salesforcecli/plugin-packaging/pull/566) * CHANGE: We removed the SF_CODE_COVERAGE_REQUIREMENT environment variable because it never did anything. (sfdx-core PR [#1023](https://github.com/forcedotcom/sfdx-core/pull/1023) * FIX: The `package version list` and `package1 version list` commands now return up to 10K records; previously the maximum was 2000. To get even more records, set the SF_ORG_MAX_QUERY_LIMIT environment variable. (GitHub issue [#2073](https://github.com/forcedotcom/cli/issues/2073), packaging PR [#500](https://github.com/forcedotcom/packaging/pull/500)) * FIX: Piping the SFDX authorization URL from stdin to the `org login sfdx-url` command is now working correctly. NOTE that as part of this fix, you're not longer required to provide the `-` value to the `--sfdx-url-stdin` flag. Here's an example; it uses the _template_ for the SFDX authorization URL, not real secret information, for obvious reasons: ```bash echo "force://::@" | sf org login sfdx-url --sfdx-url-stdin ``` (GitHub issue [#2690](https://github.com/forcedotcom/cli/issues/2690), oclif core [#935](https://github.com/oclif/core/pull/935)) * FIX: You can now correctly deploy and package source files that start with a period, such as `.specialFile`. (GitHub issue [#2666](https://github.com/forcedotcom/cli/issues/2666), source-deploy-retrieve PR [#1224](https://github.com/forcedotcom/source-deploy-retrieve/pull/1224)) ## 2.27.6 (Feb 7, 2024) * FIX: The `package version create list --created-last-days 0` command now correctly returns package versions that were created today. (GitHub issue [#2668](https://github.com/forcedotcom/cli/issues/2668), packaging PR [#496](https://github.com/forcedotcom/packaging/pull/496)) * FIX: The `project deploy quick --job-id ` command now always works correctly with 15-character deployment job IDs. If the job ID isn't in the local cache, you must provide a valid target org with the `--target-org` flag. (GitHub issue [#2591](https://github.com/forcedotcom/cli/issues/2591), plugin-deploy-retrieve PR [#884](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/884)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * GenAiPromptTemplate * GenAiPromptTemplateActv * FIX: The `org logout` command asked if you wanted to log out of all orgs when you wanted to log out of just one. The message now correctly asks about only the one org. (GitHub issue [#2671](https://github.com/forcedotcom/cli/issues/2671), plugin-auth PR [#923](https://github.com/salesforcecli/plugin-auth/pull/923)) ## 2.26.10 (Jan 31, 2024) * NEW: Choose whether Salesforce CLI capitalizes default record types when it creates a scratch org with the new Boolean `org-capitalize-record-types` configuration variable and corresponding `SF_CAPITALIZE_RECORD_TYPES` environment variable. Default record types are defined in the `objectSettings` option of a scratch org definition file, as described in [Scratch Org Definition File Options](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm). The setting is required before installing a package that creates record types. Currently, Salesforce CLI automatically capitalizes these default record types when it creates them in the scratch org, even if they're lower case in the definition file, such as `svc_Technical_Support` in this snippet: ```json "objectSettings": { "case": { "defaultRecordType": "svc_Technical_Support", "sharingModel": "private" } } ``` If you don't want Salesforce CLI to capitalize the record types, set `org-capitalize-record-types` or `SF_CAPITALIZE_RECORD_TYPES` to `false`. For example: ```bash sf config set org-capitalize-record-types=false --global ``` **Important**: Salesforce CLI plans to switch this behavior on or after June 1, 2024. See the ANNOUNCEMENT above. * FIX: We've improved source tracking so it better handles undecodable SourceMember keys; previously, the relevant command, such as `project deploy start`, would return an errror such as `URIError: URI malformed` if it encountered one. (GitHub issue [#2624](https://github.com/forcedotcom/cli/issues/2624), source-tracking PR [#531](https://github.com/forcedotcom/source-tracking/pull/531)) * FIX: We've improved the `apex run` command so it can handle SOAP responses that don't include a header when executing anonymous Apex. (GitHub issue [#2630](GitHub issue link: https://github.com/forcedotcom/cli/issues/2630), salesforcedx-apex PR [#343](https://github.com/forcedotcom/salesforcedx-apex/pull/343)) * FIX: The error output from a failed execution of the `package version create report` command now contains the correct CLI command to run to get all relevant errors (`data query` rather than the incorrect `data:soql:query`). (GitHub issue [#2660](https://github.com/forcedotcom/cli/issues/2660), plugin-packaging PR [#561](https://github.com/salesforcecli/plugin-packaging/pull/561)) ## 2.25.7 (Jan 24, 2024) * NEW: We made some groovy improvements to the `dev generate flag` command. For example: * We added a new flag type: `option`. Specify this type for flags that have a short list of pre-defined string values, similar to a picklist. The command then prompts you to enter these pre-defined values. * When you pick one of the org-related flag types for your new flag, such as `optionalOrg` or `requiredHub`, the command now asks if you want to mimic the standard Salesforce CLI flag (`--target-org` or `--target-dev-hub`, respectively). If you answer `Y`, the command uses the standard short flag name, summary, description, and default value for your new flag. You can change the long flag name if you want, or use the standard name. * When you scroll through the possible flag values, we now provide a brief description of the type at the bottom of the terminal window. * We tightened up the validation of inputted values in all the `dev generate ` commands. (plugin-dev PR [#456](https://github.com/salesforcecli/plugin-dev/pull/456)) * NEW: Open your org in an incognito window of your browser with the new `--private` flag of `org open`. This example opens your default org in an incognito window of the Chrome browser: ```bash sf org open --browser chrome --private ``` (GitHub issues [#1852](https://github.com/forcedotcom/cli/issues/1852), [#636](https://github.com/forcedotcom/cli/issues/636), and [#2262](https://github.com/forcedotcom/cli/discussions/2262); plugin-org PR [#923](https://github.com/salesforcecli/plugin-org/pull/923)) * NEW: The JSON output of the `package version create` command now contains more information: the package name and whether code coverage tests were run and the resulting code coverage percentage is 75% or greater. These values correspond to the Tooling API `Package2.Name` and `Package2Version.HasPassedCodeCoverageCheck` fields. (packaging library PRs [#486](https://github.com/forcedotcom/packaging/pull/486) and [#466](https://github.com/forcedotcom/packaging/pull/466)) Many thanks to [Ronny Rokitta](https://github.com/Rocko1204) for this contribution. We love it. * FIX: If the `package version create` command times out, the output now includes a request ID so you can later query the status of the package version create request with the `package version create report --package-create-request-id ` command. (GitHub issue [#2605](https://github.com/forcedotcom/cli/issues/2605), packaging library PR [#485](https://github.com/forcedotcom/packaging/pull/485)) * FIX: Salesforce CLI no longer includes security tokens in the URL used to open an org in a browser with the `org open` command. (plugin-org PR [#913](https://github.com/salesforcecli/plugin-org/pull/913)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * ExtlClntAppNotificationSettings * DataCalcInsightTemplate * DataKitObjectTemplate ## 2.24.4 (Jan 17, 2024) * NEW: Pipe the SFDX authorization URL through standard input when executing the `org login sfdx-url` command by specifying the new `--sfdx-url-stdin` flag and providing the `-` character as the value. Here's an example; it uses the _template_ for the SFDX authorization URL, not real secret information, for obvious reasons: ``` echo "force://::@" | sf org login sfdx-url --sfdx-url-stdin - ``` Many thanks to [Kyle Capehart](https://github.com/k-capehart) for contributing this cool new feature. Awesome sauce. We look forward to more contributions from you! (GitHub issue #[2120](https://github.com/forcedotcom/cli/issues/2120), plugin-auth PR [#886](https://github.com/salesforcecli/plugin-auth/pull/886)) * FIX: The `project deploy start` command now correctly returns exit code 1 if you explicitly specify something to deploy (such as `--manifest package.xml` or `--source-dir force-app`) but nothing is deployed. If you don't specify anything, and nothing is deployed, the exit code is 0. (GitHub issue [2621](https://github.com/forcedotcom/cli/issues/2621), plugin-deploy-retrieve PR [862](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/862)) * FIX: Salesforce DX projects now support these [metadata types](https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json): * ExpressionSetObjectAlias * ExtDataTranObjectTemplate * ExtDataTranFieldTemplate ## 2.23.20 (Jan 10, 2024) * NEW and CHANGED (two for one!): We improved the output of the `sf commands` command so that it no longer displays deprecated commands and deprecated aliases of commands; the output is now cleaner and easier to read. Don't worry, you can still see all the deprecated stuff with the new `--deprecated` flag. (oclif/plugin-commands PR [#568](https://github.com/oclif/plugin-commands/pull/568)) ```bash sf commands --deprecated ``` * CHANGE: We generally cleaned up how we manage and display deprecated and hidden commands. For example, all deprecated commands now display appropriate and consistent warnings when you run them. Also, hidden commands no longer show up when you use autocomplete. (If you already use autocomplete, be sure to run `sf autocomplete --refresh-cache` to get this change.) (plugin-source PR [#1050](https://github.com/salesforcecli/plugin-source/pull/1050), plugin-auth PR [#905](https://github.com/salesforcecli/plugin-auth/pull/905), plugin-schema PR [#668](https://github.com/salesforcecli/plugin-schema/pull/668), plugin-limits PR [#739](https://github.com/salesforcecli/plugin-limits/pull/739), plugin-user PR [#835](https://github.com/salesforcecli/plugin-user/pull/835), plugin-org PR [#914](https://github.com/salesforcecli/plugin-org/pull/914)) * FIX: You can now successfully create a Partner Developer Edition scratch org with the `org create scratch --edition partner-developer` command. (GitHub issue [#2614](https://github.com/forcedotcom/cli/issues/2614), plugin-org PR [#916](https://github.com/salesforcecli/plugin-org/pull/916)) ## 2.22.7 (Jan 3, 2023) * NEW: These scratch org snapshot commands are now beta; they were previously pilot. * `org create snapshot` * `org delete snapshot` * `org get snapshot` * `org list snapshot` A snapshot is a point-in-time copy of a scratch org. It captures the state of a scratch org’s configuration so that you can use it to create scratch org replicas. Snapshots are available when your Dev Hub org is upgraded to the Spring ’24 release. Then enable Scratch Org Snapshots in the Dev Hub org that you use to create scratch orgs. For more information, see [Scratch Org Snapshots](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_snapshots_intro.htm). (Available December 20, 2023, when the Spring '24 documentation is in preview.) * NEW: When previewing a retrieve with the `project retrieve preview` command, use the new `--concise` flag to show only the changes that will be retrieved. The output also omits the files that are in the `.forceignore` file. For example: ```bash sf project retrieve preview --metadata ApexClass --target-org my-scratch --concise ``` (GitHub issue [#2489](https://github.com/forcedotcom/cli/discussions/2489), plugin-deploy-retrieve PR [#831](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/831)) * FIX: Salesforce CLI now checks your local plugin allow list (specifically the `unsignedPluginAllowList.json` file) before it makes a callout to an npm registry endpoint. As a result, installs of allowed plugins are now faster. (GitHub issue [#2584](https://github.com/forcedotcom/cli/issues/2584), plugin-trust PR [#668](https://github.com/salesforcecli/plugin-trust/pull/668)) * FIX: Salesforce DX projects now support these metadata types: * SvcCatalogFilterCriteria * SvcCatalogFilterCondition * SvcCatalogItemDefFiltrCrit ## Dec 20 and 27, 2023 Due to the holiday break in the United States, we aren't releasing new stable versions on Dec 20 or Dec 27. Happy holidays! ## 2.21.7 (Dec 13, 2023) * NEW: View the namespace associated with an org with the new `Namespace` column of the `sf org list --verbose` command. If an org doesn't have a namespace, the value is blank. (GitHub issue [#1790](https://github.com/forcedotcom/cli/issues/1790), plugin-org PR [#596](https://github.com/salesforcecli/plugin-org/pull/596)) Many thanks to [atsutton](https://github.com/atsutton) for contributing the code for this new feature! It's a nice improvement to the command. Keep 'em coming! * FIX: We improved the error message when you try to run `org create user` on a scratch org whose associated Dev Hub is running on Hyperforce and you authorized it with JWT. Salesforce doesn't support this use case. To work around it, try authorizing the Dev Hub using the `org login web` or `org login sfdx-url` commands instead of `org login jwt`. (GitHub issue [#2575](https://github.com/forcedotcom/cli/issues/2575), plugin-user PR [#805](https://github.com/salesforcecli/plugin-user/pull/805)) * FIX: Using wildcards when retrieving metadata that isn't yet in your local project with the `project retrieve start --metadata` command now works as expected. For example, `project retrieve start --metadata "ApexClass:MyClass*` now always correctly retrieves all Apex classes that start with `MyClass`. (GitHub issue [#2522](https://github.com/forcedotcom/cli/issues/2522), source-deploy-retrieve PR [#1182](https://github.com/forcedotcom/source-deploy-retrieve/pull/1182)) * FIX: When running Apex tests, Salesforce CLI now correctly displays test names that include a namespace. (GitHub issue [#296](https://github.com/forcedotcom/salesforcedx-apex/issues/296), salesforcedx-apex PR [#339](https://github.com/forcedotcom/salesforcedx-apex/pull/339)) Shout-out and thanks to [Jonny Power](https://github.com/JonnyPower) for contributing the fix! We love it. * FIX: When you install an unsigned plugin that's in the `unsignedPluginAllowList.json` file, the `plugins install` command now bypasses _any_ HTTP 403 error, not just `403 Forbidden`. (GitHub issue [#2584](https://github.com/forcedotcom/cli/issues/2584), plugin-trust [#662](https://github.com/salesforcecli/plugin-trust/pull/662)) Thank you [kyle-blair](https://github.com/kyle-blair) for contributing the fix! You're the best. ## 2.20.7 (Dec 6, 2023) * NEW: We've improved source tracking and the output of the `project deploy start` command in various ways: * We now output a warning if a tracked source file doesn't create a SourceMember Tooling API record in the org, or creates one with an unexpected name. During a deployment, Salesforce CLI waits for these events to complete, and depending on the deployment size and the fact that these kinds of events may never complete, the deployment appears stuck. These warnings give you more insight into what's happening. If you notice the same warning consistently, open a GitHub issue so we can stop unnecessarily waiting for it. * The progress bar now also includes the progress of SourceMember polling in the org. * The status bar hides errors and tests if there are none. (GitHub issue [#2495](https://github.com/forcedotcom/cli/issues/2495), source-tracking PR [#511](https://github.com/forcedotcom/source-tracking/pull/511), deploy-retrieve PRs [#819](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/819) and [#820](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/820)) * CHANGE: When installing Salesforce CLI on Windows with the `.exe` installer, the option in the Choose Components window to **Add %LOCALAPPDATA%\sf to Windows Defender exclusions** is now deselected by default. We changed the behavior because we wanted the default Windows installation to be more secure. However, excluding the CLI files from the antivirus scans improves the performance of Salesforce CLI, so select the option if you want. But use with caution. (salesforce/cli PR [#1328](https://github.com/salesforcecli/cli/pull/1328)) * FIX: When running `cmdt generate records` and the referenced CSV file doesn't include a value for a field, the command now skips the field; previously it incorrectly inserted an `undefined` value. (GitHub issues [#2074](https://github.com/forcedotcom/cli/issues/2074) and [#1714](https://github.com/forcedotcom/cli/issues/1714), plugin-custom-metadata PR [#662](https://github.com/salesforcecli/plugin-custom-metadata/pull/662)) * FIX: We updated the summary of the `--suite-names` flag of `apex run test` to no longer say the default value is all Apex test suites. The flag has no default value, and it's not possible to run all suites. (GitHub issue [#2580](https://github.com/forcedotcom/cli/issues/2580), plugin-apex PR [#294](https://github.com/salesforcecli/plugin-apex/pull/294)) ## 2.19.7 (Nov 29, 2023) * NEW: If you specify Apex tests with the `--tests` flag of `project deploy start|validate`, the `--test-level` flag defaults to `RunSpecifiedTests`. (GitHub issue [#2396](https://github.com/forcedotcom/cli/issues/2396), plugin-deploy-retrieve PR [#812](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/812)) Many thanks to Christopher Bohlman ([cbohlman](https://github.com/cbohlman)) for contributing the code. We put out a "Help Wanted" call, and he answered with aplomb. Community Collaboration in Action -- we love it! * NEW: Manage source tracking in existing orgs with these two new commands: * `org enable tracking`: Allow Salesforce CLI to track changes in your source files between your project and an org. * `org disable tracking`: Prevent Salesforce CLI from tracking changes in your source files between your project and an org. Enabling or disabling source tracking has no direct effect on the org, it affects only your local environment. Specifically, Salesforce CLI stores the setting in the org's local configuration file so that source tracking operations are, or aren't, executed when working with the org. Run the `org enable tracking` command on orgs that support source tracking, such as scratch orgs and Developer and Developer Pro sandboxes. The command returns an error if the org doesn't support tracking. Examples of orgs that don't support source tracking include Developer Edition orgs, production orgs, Partial Copy sandboxes, and Full sandboxes. As an example, imagine you have a sandbox that you use for integration tests, and you want to deploy source to it but not wait for tracking operations. This example shows how to disable source tracking on an org with alias `mySandbox`: ```bash sf org disable tracking --target-org mySandbox ``` (GitHub issue [#2495](https://github.com/forcedotcom/cli/issues/2495), plugin-org PR [#868](https://github.com/salesforcecli/plugin-org/pull/868)) * NEW: Ignore warnings and allow a deployment to validate successfully with the new `--ignore-warnings` flag of `project deploy validate`. This flag is similar to the equivalent flag of `project deploy start`. (GitHub issue [#2559](https://github.com/forcedotcom/cli/issues/2559), plugin-deploy-retrieve PR [#803](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/803)) * CHANGE: We've added exit codes for many Salesforce CLI command failures to better help you understand what happened. In particular, commands that: * Exit from a user-initiated Ctrl-C now return exit code 130. (sf-plugins-core PR [#445](https://github.com/salesforcecli/sf-plugins-core/pull/445)) * Fail due to an internal Salesforce error (AKA "gack") now return exit code 20. (sf-plugins-core PR [#442](https://github.com/salesforcecli/sf-plugins-core/pull/442)) * Fail due to a `TypeError` now return exit code 10. (sf-plugins-core PR [#442](https://github.com/salesforcecli/sf-plugins-core/pull/442)) * CHANGE: We've removed the `--json` flag of the `apex log tail` command. Why? Because it didn't make much sense in the first place. The only way to exit the command is to enter Ctrl-C, so the JSON output can't be captured. And don't worry, we checked our telemetry data: this flag is hardly ever used. Get logs in JSON format with the `apex list log` or `apex get log` commands. (plugin-apex PR [#280](https://github.com/salesforcecli/plugin-apex/pull/280)) * CHANGE: We removed the `plugin-login` plugin from Salesforce CLI. The plugin contained two general commands, both of which are deprecated: `org login` and `org logout`. Use specific commands instead, such as `org login web` or `org login jwt`. * CHANGE: We converted `plugin-packaging` from a JIT to a core plugin. This change doesn't fix the root cause of GitHub issue [2540](https://github.com/forcedotcom/cli/issues/2540) but should help some users who commented there. * FIX: Your CLI configuration files are now cross-save safe. Wow! But what does that mean? Well, Salesforce CLI would sometimes try to save 2 copies of the same file concurrently, resulting in either an invalid JSON file or one of the "savers" losing their changes. To fix this issue, we redesigned how files are saved to try to be safer about concurrency. This fix applies to configuration files that you know and love, such as `sfdx-project.json` and org config files, as well as internal files that keep track of your configuration values, org authorization information, and various caches. (GitHub issues [#2423](https://github.com/forcedotcom/cli/issues/2423) and [#2528](https://github.com/forcedotcom/cli/issues/2528), sfdx-core PR [#959](https://github.com/forcedotcom/sfdx-core/pull/959)) * FIX: The `org login access-token` command now honors the SF_ACCESS_TOKEN environment variable, in addition to SFDX_ACCESS_TOKEN. Side note: We encourage you to use the SF_ env vars because the old SFDX_ ones might go away one day. We also fixed the `--help` for the command to mention SF_ACCESS_TOKEN. (GitHub issue [#2574](https://github.com/forcedotcom/cli/issues/2574), plugin-auth PR [#864](https://github.com/salesforcecli/plugin-auth/pull/864)) * FIX: The `cmdt generate records` command now correctly handles CSV files that produce non-unique custom metadata type record names. (GitHub issue [#2573](https://github.com/forcedotcom/cli/issues/2573), plugin-custom-metadata PR [#655](https://github.com/salesforcecli/plugin-custom-metadata/pull/655)) * FIX: The `project deploy quick` command now correctly waits for the quick deploy to finish, and then returns the results of the quick deploy and not of the original validate deploy. (GitHub issue [2537](https://github.com/forcedotcom/cli/issues/2537), plugin-deploy-retrieve PR [#815](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/815)) * FIX: If the `project deploy start` command fails to deploy a component, it now always displays the error along with the name of the failed component. (GitHub issue [2561](https://github.com/forcedotcom/cli/issues/2561), plugin-deploy-retrieve PR [#816](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/816)) * FIX: We've updated the flag descriptions of the `--target-org` and `--target-dev-hub` flags in all relevant commands to say that the flag isn't required if the related configuration value (`target-org` and `target-dev-hub`) is set. (GitHub issue [#2538](https://github.com/forcedotcom/cli/issues/2538), sf-plugins-core PR [#455](https://github.com/salesforcecli/sf-plugins-core/pull/455)) * FIX: We've fixed a bug when running `apex run test -r junit` or `apex get test -r junit` in which you sometimes got the error `Invalid time value`. (GitHub issue [#213](https://github.com/forcedotcom/salesforcedx-apex/issues/213), salesforcedx-apex PR [334](https://github.com/forcedotcom/salesforcedx-apex/pull/334)) * FIX: Salesforce CLI now correctly catches errors that are thrown when looking for decoded keys. (GitHub issue [#2560](https://github.com/forcedotcom/cli/issues/2560), source-deploy-retrieve PR [#1167](https://github.com/forcedotcom/source-deploy-retrieve/pull/1167)) * FIX: You can now successfully run a command that's in a JIT plugin, but not yet installed, with the `--json` flag. For example, if you previously ran `sf package version create --json`, but the JIT plugin-packaging plugin wasn't yet installed, the plugin would be automatically installed but you'd get garbled and incorrect JSON command output. Now the JSON output is as clean as the proverbial whistle. (GitHub issue [#2562](https://github.com/forcedotcom/cli/issues/2562), plugin-trust PR [#643](https://github.com/salesforcecli/plugin-trust/pull/643), oclif plugin-plugins PR [#712](https://github.com/oclif/plugin-plugins/pull/712)) * FIX: Salesforce CLI now correctly honors the `SF_DISABLE_LOG_FILE=true` environment variable setting without returning an error. (GitHub issue [#2553](https://github.com/forcedotcom/cli/issues/2553), sfdx-core PR [#979](https://github.com/forcedotcom/sfdx-core/pull/979)) ## Nov 22, 2023 Due to the Thanksgiving break in the United States, we aren't releasing a new stable version today. Happy Thanksgiving! ## 2.17.14 (Nov 15, 2023) * NEW: Easily uninstall all user-installed and linked plugins, including JIT plugins, with the new `plugins reset` command. ```bash sf plugins reset ``` After you run the command, you're left with only the core Salesforce CLI plugins, as if you had just installed the CLI from scratch. (oclif plugin-plugins PR [#701](https://github.com/oclif/plugin-plugins/pull/701)) * CHANGE: We've changed the official names of these commands that display org limits and counts. Both the new and old names work, but the [CLI Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_unified.htm) will soon list only the new name. (plugin-limits PR [#673](https://github.com/salesforcecli/plugin-limits/pull/673)) |New Name|Old Name|Description| |---|---|---| |`org list limits`|`limits api display`|Display information about limits in your org.| |`org list sobject record-counts`|`limits recordcounts display`|Display record counts for the specified standard or custom objects.| * FIX: Salesforce CLI now handles the `SF_CONTAINER_MODE` and `SF_DOMAIN_RETRY` environment variables; previously it handled only the old `SFDX_` equivalents (`SFDX_CONTAINER_MODE` and `SFDX_DOMAIN_RETRY`). And `SF_CONTAINER_MODE` [isn't documented](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_env_variables.htm) -- oopsie! We're in the process of fixing that doc bug too. (GitHub issue [#2554](https://github.com/forcedotcom/cli/issues/2554), plugin-org PR [#857](https://github.com/salesforcecli/plugin-org/pull/857)) * FIX: We've improved how `sf plugins install https://github.com/foo/bar` works, which sometimes returned an error. (oclif plugin-plugins PR [#702](https://github.com/oclif/plugin-plugins/pull/702)) * FIX: Installing a plugin on Windows with the `sf plugins install` command no longer returns an error if the path to the Node.js binary contains a space. (GitHub issue [#2465](https://github.com/forcedotcom/cli/issues/2564), oclif plugin-plugins PR [#711](https://github.com/oclif/plugin-plugins/pull/711), [#718](https://github.com/oclif/plugin-plugins/pull/718)) * FIX: Salesforce DX projects now support these metadata types. (GitHub issue [#2527](https://github.com/forcedotcom/cli/issues/2527)) * CareBenefitVerifySettings * CareProviderAfflRoleConfig * ContextDefinition * DiscoveryStory * DocumentCategory * DocumentCategoryDocumentType * ExpressionSetMessageToken * ExternalAIModel * ManagedEventSubscription * RecordAggregationDefinition * RegisteredExternalService * WebStoreBundle ## 2.16.7 (Nov 8, 2023) * NEW: Use the new `scopeProfiles` option of the `sfdx-project.json` file to control which profile settings are included in a new package version when you run the `package create version` command. If you set `scopeProfiles` to `true` for a package directory, profile settings from only the package directory being packaged are included, and profile settings outside of that package directory are ignored. When you set `scopeProfiles` to `false` (the default value), the new package version includes relevant pieces of profile settings in any package directory defined in `sfdx-project.json`. The `scopeProfiles` option is a child of `packageDirectory`, as shown in this example. ``` { "packageDirectories": [ { "path": "force-app", "package": "TV_unl", "scopeProfiles": "true", "versionName": "ver 0.1", "versionNumber": "0.1.0.NEXT", "default": true, "unpackagedMetadata": { "path": "my-unpackaged-directory" } } ], "namespace": "", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "58.0" } ``` (packaging PR [#416](https://github.com/forcedotcom/packaging/pull/416), schemas PR [#80](https://github.com/forcedotcom/schemas/pull/80), sfdx-core PR [#957](https://github.com/forcedotcom/sfdx-core/pull/957)) * CHANGE: We upgraded the version of Node.js bundled in the Salesforce CLI operating system-specific installers, TAR files, and Docker images to v20. Why? Because we always bundle the Active LTS version of Node.js in tandem with its [release schedule](https://github.com/nodejs/release#release-schedule), and v20 went LTS on October 24, 2023. * FIX: We've improved the output of the `sf plugins install` command. For example, the warnings are better grouped and you no longer see duplicate warnings. And the final message clearly states that the plugin was successfully installed, if indeed it was. (oclif plugin-plugin PR [#683](https://github.com/oclif/plugin-plugins/pull/683)) * FIX: The `project retrieve start` command now correctly retrieves CustomFieldTranslation metadata types across multiple package directories. (GitHub issue [#2124](https://github.com/forcedotcom/cli/issues/2124), source-deploy-retrieve PR [#1146](https://github.com/forcedotcom/source-deploy-retrieve/pull/1146)) * FIX: The `--help` output for some commands no longer shows `[object Object]` for the default value of some flags; the output now shows the actual default value. An example of a command with the incorrect `--help` output was `org create scratch`. (GitHub issue [#2539](https://github.com/forcedotcom/cli/issues/2539), oclif core PR [#844](https://github.com/oclif/core/pull/844)) * FIX: You can now use the `--dev-debug` flag on its own to get debug log files from oclif and Salesforce CLI when you run a command; previously you also had to set the SF_LOG_LEVEL environment variable. If the environment variable isn't set, then the default log level is `trace`. (salesforcecli PR [#1246](https://github.com/salesforcecli/cli/pull/1246)) ## 2.15.9 (Nov 1, 2023) * NEW: The `dev convert script` command for migrating your CI scripts to use the `sf`-style commands now handles `sfdx` commands that span multiple lines. For example, the command converts this: ```bash sfdx force:user:create -f config/user-def.json \ -a myuser \ -u myorg ``` into this: ```bash sf org create user --definition-file config/user-def.json \ --set-alias myuser \ --target-org myorg ``` (plugin-dev PR [#402](https://github.com/salesforcecli/plugin-dev/pull/402)) * FIX: The `org list` command now correctly renders the output when a listed org has expired or been deactivated, such as a [developer edition org](https://help.salesforce.com/s/articleView?id=sf.admin_deactivate_org.htm&type=5). (GitHub issue [#2533](https://github.com/forcedotcom/cli/issues/2533), plugin-org PR [#845](https://github.com/salesforcecli/plugin-org/pull/845)) * FIX: Salesforce CLI now correctly handles internal alias files that aren't in the expected format. (sfdx-core PR [#969](https://github.com/forcedotcom/sfdx-core/pull/969)) ## 2.14.6 (Oct 25, 2023) * NEW: Disable Salesforce CLI version checking with the new `SF_SKIP_NEW_VERSION_CHECK` environment variable. By default, every CLI command execution checks whether there's a new CLI version available, and prints out a warning message if it finds one. While this message is useful, it's not always wanted, especially in CI environments. To completely disable the check, set `SF_SKIP_NEW_VERSION_CHECK=true`. Alternatively, you can configure the frequency of the warning message, such as once a day, by setting these two environment variables: * `SF_NEW_VERSION_CHECK_FREQ`: A number that specifies the frequency that the warning message is displayed. Default is `0`, which displays the message every time a new version is found. * `SF_NEW_VERSION_CHECK_FREQ_UNIT`: The unit of time of the frequency. Possible values are `days`, `hours`, `minutes` (the default value), `seconds`, and `milliseconds`. For example, to get the warning message once a day, set `SF_NEW_VERSION_CHECK_FREQ=1` and `SF_NEW_VERSION_CHECK_FREQ_UNIT=days`. Note that these two `FREQ` environment variables configure only when the warning is displayed; the version check still occurs for each command execution unless you set `SF_SKIP_NEW_VERSION_CHECK=true`. [oclif/plugin-warn-if-update-available PR [#437](https://github.com/oclif/plugin-warn-if-update-available/pull/437)) * NEW: Open a flow in Flow Builder from the command line by passing the local Flow metadata file to `org open --source-file`. For example, to open the local Hello flow in Flow Builder: ```bash sf org open --source-file force-app/main/default/flows/Hello.flow-meta.xml ``` Many thanks to [Arturs Gusjko](https://github.com/GusjkoA) who not only came up with the great idea, but also provided [excellent QA and suggestions](https://github.com/salesforcecli/plugin-org/pull/836) to help us release a better feature. Terrific community collaboration! (GitHub issue [#2519](https://github.com/forcedotcom/cli/discussions/2519), plugin-org PR [#829](https://github.com/salesforcecli/plugin-org/pull/829)) * FIX: We corrected the help for `config list` to say that the command lists the config variable values based on the current context. For example, if you run the command from a project which has a local config variable set, but it's also set globally, the command prints the local value which overrides the global one. (GitHub issue [#2435](https://github.com/forcedotcom/cli/issues/2435), plugin-settings [#405](https://github.com/salesforcecli/plugin-settings/pull/405)) * FIX: The `SF_NPM_REGISTRY` environment variable is now working correctly. (GitHub issue [#2517](https://github.com/forcedotcom/cli/issues/2517), plugin-trust PR [#618](https://github.com/salesforcecli/plugin-trust/pull/618)) ## 2.13.9 (Oct 18, 2023) * FIX: If the `project deploy start --metadata-dir` command encounters failures when deploying files in metadata format, the error message now contains the line and column number in the file where the error occurred. We also improved the output with better sorting and duplication removal. (GitHub issue [#356](https://github.com/forcedotcom/cli/issues/356), plugin-deploy-retrieve PR [#771](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/771)) * FIX: We improved the help of the `org generate password` command to say that the `--on-behalf-of` flag works only on users that were created locally with the `org create user` command and not users created in org's Setup UI. (GitHub issue [#2506](https://github.com/forcedotcom/cli/issues/2506), plugin-user PR [#747](https://github.com/salesforcecli/plugin-user/pull/747)) * FIX: Salesforce DX projects now support the EventRelayConfig metadata type. ## 2.12.9 (Oct 11, 2023) * CHANGE: Salesforce CLI now prompts you to select a matching command, even when the partial command you entered matches just a single command. This change prevents inadvertent behavior, such as automatic JIT plugin installations because the CLI thinks you want to run a command in a JIT plugin that isn't installed. (GitHub issue [#2493](https://github.com/forcedotcom/cli/issues/2493), salesforcecli PR [#1180](https://github.com/salesforcecli/cli/pull/1180)) * FIX: The `org resume sandbox` command now correctly handles multiple sandboxes in a resumable state. It first displays a warning about the multiple sandboxes, and then resumes the most recent sandbox creation or refresh. (GitHub issues [#2238](https://github.com/forcedotcom/cli/issues/2238) and [#1833](https://github.com/forcedotcom/cli/issues/1833), sfdx-core PR [#944](https://github.com/forcedotcom/sfdx-core/pull/944), plugin-org PR [#823](https://github.com/salesforcecli/plugin-org/pull/823)) * FIX: The `--help` output of a deprecated aliased command (such as `force:org:list`) now displays the deprecation warning. (GitHub oclif issue [#800](https://github.com/oclif/core/issues/800), oclif PR [#801](https://github.com/oclif/core/pull/801)) * FIX: Certain `package` commands now display the error when they fail; previously they failed silently. (GitHub issues [#2434](https://github.com/forcedotcom/cli/issues/2434) and [#2469](https://github.com/forcedotcom/cli/issues/2469), packaging PR [#403](https://github.com/forcedotcom/packaging/pull/403)) * FIX: The CLI's source tracking library now prevents the registration of duplicate listeners. When the Salesforce Extensions for VS Code release an update with the updated source tracking library, the library will prevent the extensions from registering duplicate listeners. (GitHub issues [#2441](https://github.com/forcedotcom/cli/issues/2441), [#2458](https://github.com/forcedotcom/cli/issues/2458), [#2483](https://github.com/forcedotcom/cli/issues/2483), [#2476](https://github.com/forcedotcom/cli/issues/2476), and [#2439](https://github.com/forcedotcom/cli/issues/2439). source-tracking PR [#480](https://github.com/forcedotcom/source-tracking/pull/480), sfdx-core PR [#941](https://github.com/forcedotcom/sfdx-core/pull/941)) * FIX: HTML entities, such as ` ` in a CustomLabels metadata type, are now correctly encoded when deployed to an org. (GitHub issues [#2448](https://github.com/forcedotcom/cli/issues/2448) and [#2455](https://github.com/forcedotcom/cli/issues/2455), SDR PRs [#1102](https://github.com/forcedotcom/source-deploy-retrieve/pull/1102) and [#1128](https://github.com/forcedotcom/source-deploy-retrieve/pull/1128)) * FIX: The `org list` and `org display` commands no longer display the raw HTML 503 response when run against an org on an instance that's currently out of service. (GitHub issue [#2487](https://github.com/forcedotcom/cli/issues/2487), plugin-org PR [#814](https://github.com/salesforcecli/plugin-org/pull/814)) * FIX: Salesforce DX projects now support these metadata types: * ConversationChannelDefinition * ExtlClntAppConfigurablePolicies ## 2.11.8 (Oct 4, 2023) * NEW: Plugin installs use `yarn` under the hood. If you run into errors during installs or updates, you can now enable the network mutex option by setting the SF_USE_NETWORK_MUTEX environment variable to `true`. Setting this variable opens a local network to manage the concurrent `yarn` instances and may be more reliable. You can also pass an optional port for the local server to open on with the SF_NETWORK_MUTEX_PORT environment variable. See the [yarn documentation](https://classic.yarnpkg.com/lang/en/docs/cli/#toc-concurrency-and-mutex) for more information. [oclif plugin-plugins PR [#670](https://github.com/oclif/plugin-plugins/pull/670)) * NEW: Poll for status of a deployment when you run `project deploy report` with the new `--wait` flag. If you specify this flag, the command polls for the status every second until the timeout of `--wait` minutes. If you don't specify the `--wait` flag, the command simply checks and displays the status of the deploy; the command doesn't poll for the status. We also added the `--target-org` flag to `project deploy report`. You usually don't need to specify this flag because the cached deploy job already references the org to which you deployed. But if you run `project deploy report` on a computer different than the one from which you originally deployed, and the default org is different from the deployment org, then you must specify `--target-org`. The flag must point to the same deployment org; if it doesn't, you get an error. Finally, you no longer get an error if you run `project deploy resume` on a deployment that finished. Instead you get a message telling you that it completed and then the deploy results. (GitHub discussion [#2300](https://github.com/forcedotcom/cli/discussions/2300) and issues [#2293](https://github.com/forcedotcom/cli/issues/2293), [#2297](https://github.com/forcedotcom/cli/issues/2297), [#2078](https://github.com/forcedotcom/cli/issues/2078). plugin-deploy-retrieve PRs [#762](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/762) and [#758](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/758)) * CHANGE: We removed the `package version retrieve` command that we announced on September 15, 2023. This feature isn't quite ready for prime time, so we're removing it for now while we make improvements. We'll let you know after it's back up. (plugin-packaging PR [#447](https://github.com/salesforcecli/plugin-packaging/pull/447)) * FIX: When you create a package version with the `package version create` command, the command now searches for profiles in the package directories defined in `sfdx-project.json`. (GitHub issue [#2336](https://github.com/forcedotcom/cli/issues/2336), packaging PR [#397](https://github.com/forcedotcom/packaging/pull/397)) * FIX: Salesforce DX projects now support the PricingRecipe metadata type. ## 2.10.2 (Sept 27, 2023) * NEW: Code Coverage UI Improvements. We changed the code coverage colors to indicate good, average, and poor coverage. (GitHub Issue [#2412](https://github.com/forcedotcom/cli/issues/2412), plugin-deploy-retrieve PR [#756](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/756), plugin-source PR [#950](https://github.com/salesforcecli/plugin-source/pull/950), plugin-source PR (superseded) [#934](https://github.com/salesforcecli/plugin-source/pull/934)) Thank you @AllanOricil for your contributions to `plugin-source`! :heart: * NEW: Uninstalled JIT Plugins are now displayed when you run `sf plugins --core [--json]`. The command displays a warning if you try to inspect an uninstalled JIT plugin. * FIX: Uncovered line numbers are now correctly displayed in the Code Coverage report when you run `project deploy report`. (GitHub Issue [#2468](https://github.com/forcedotcom/cli/issues/2468), plugin-source PR [#950](https://github.com/salesforcecli/plugin-source/pull/950)) * FIX: The `.forceignore` file now correctly handles an opt-in style with directories. (GitHub Issue [#2404](https://github.com/forcedotcom/cli/issues/2404), source-deploy-retrieve PR [#1093](https://github.com/forcedotcom/source-deploy-retrieve/pull/1093)) * FIX: Running `project deploy quick` now displays the deploy ID of the quick deploy request, not the validation ID. (GitHub Issue [#2415](https://github.com/forcedotcom/cli/issues/2415), source-deploy-retrieve PR [#748](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/748)) ## 2.9.8 (Sept 20, 2023) * NEW: Salesforce CLI now shows a warning when the version of a core or JIT plugin is out of sync with what was shipped with your installed CLI. * NEW: JIT plugins now respect a lock file during install. This new behavior prevents JIT plugins from installing dependencies that are newer than what they were shipped and tested with. * FIX: Running `project retrieve start` now shows warnings for problematic components. This behavior matches the functionality of `force:source:retrieve` (GitHub issue [#2405](https://github.com/forcedotcom/cli/issues/2405), plugin-deploy-retrieve PR [#747](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/747)) * FIX: Metadata transfers now automatically retry when they encounter an `ENOMEM` error. Keeps your eyes out for Shane McLaughlin's [debut album](https://github.com/forcedotcom/cli/issues/2452#issuecomment-1710027941). (GitHub issue [#2452](https://github.com/forcedotcom/cli/issues/2452), source-deploy-retrieve PR [#1103](https://github.com/forcedotcom/source-deploy-retrieve/pull/1103)) ## 2.8.11 (Sept 15, 2023) * NEW: Download metadata from a specific package version with the new `package version retrieve` command. You can retrieve metadata for a second- or first-generation managed package or an unlocked package. Retrieving a package version downloads the metadata into the directory you specify. When you run the command, specify the package alias or the subscriber package version ID (starts with 04t) and the path to an empty directory. To use this command you must have the Download Package Version Zip Files user permission. In this example, the org that owns the package has an alias of `my-org`, and we're retrieving the metadata from a package version with ID `04tXXX`. The metadata is downloaded into the `my-directory` directory: ```bash sf package version retrieve --package 04tXXX --output-dir my-directory --target-org my-org ``` * NEW: Enable AppExchange App Analytics usage data collection on a managed package and its components with the new `--enable-app-analytics` flag of the `package update` command. See [Enable App Analytics on Your Second-Generation Managed Package ](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/app_analytics_enable_2gp.htm) for more information. (plugin-packaging [#325](https://github.com/salesforcecli/plugin-packaging/pull/325)) * FIX: We've updated the message displayed when you install an unsigned plugin using the `plugins install` command to be more friendly. (plugin-trust PR [#581](https://github.com/salesforcecli/plugin-trust/pull/581)) * FIX: We've improved the description of the `project generate` subtopic in the `package.json` file to include generating a project, manifest, and more. Thanks, [Peter Chittum](https://github.com/pchittum), for your contribution -- we love it! (plugin-deploy-retrieve PR [#742](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/742)) ## 2.7.11 (Sept 6, 2023) * NEW: Execute DevOps Center actions at the command line with these new beta CLI commands: * `project deploy pipeline start`: Deploy changes from a branch to the pipeline stage’s org. * `project deploy pipeline report`: Check the status of a pipeline deploy operation. * `project deploy pipeline validate`: Perform a validate-only deployment from a branch to the pipeline stage’s org. * `project deploy pipeline quick` : Quickly deploy a validated deployment to an org. * `project deploy pipeline resume`: Resume watching a pipeline deploy operation. We created these commands for developers who want to work outside of DevOps Center or want to automate tasks. The commands are in [plugin-devops-center](https://github.com/salesforcecli/plugin-devops-center), which is a just-in-time (JIT) plugin. After you update to this Salesforce CLI release, run a DevOps Center command in a terminal or command window and the CLI automatically installs the plugin and then runs the command. Nifty, huh. Let's look at a few examples to see how the new beta commands work. In this example, several work item feature branches were previously merged to the `recruit-integration` branch. To deploy the changes from the `recruit-integration` branch to its associated Integration environment: ```bash sf project deploy pipeline start --branch-name recruit-integration --devops-center-username MyDevOpsCenterOrg --devops-center-project-name "Recruiting App" ``` In this example, UAT is the bundling stage, which means that you must indicate a version identifier with the `--bundle-version-name` flag. To deploy all merged changes in a version 1.0 bundle to the UAT environment: ```bash sf project deploy pipeline start --branch-name recruit-uat --devops-center-username MyDevOpsCenterOrg --devops-center-project-name "Recruiting App" --bundle-version-name 1.0 ``` In this example, you first validate the changes in the `recruit-staging` branch so you can later perform a quick deployment to production. The validate command returns a job ID that you later pass to the quick deploy command. ```bash sf project deploy pipeline validate --branch-name recruit-staging --devops-center-username MyDevOpsCenterOrg --test-level RunLocalTests --devops-center-project-name "Recruiting App" ``` When ready, execute the quick deployment to production by specifying the job ID returned by the validate command: ```bash sf project deploy pipeline quick --job-id 0Af0x000017yLUFCA2 ``` You can also use the new `target-devops-center` configuration variable to specify the default username or alias for the org in which DevOps Center is installed. Use it instead of the `--devops-center-username` flag. For example, to set the config variable globally: ```bash sf config set target-devops-center MyDevOpsCenterOrg --global ``` As always, run the new commands with the `--help` flag to see more examples and information. Enjoy! * NEW: Find 3rd-party (not created by Salesforce) CLI plugins with `sf plugins discover`. The command uses [this list of packages](https://github.com/salesforcecli/plugin-marketplace/blob/main/src/shared/plugins.ts) to query npm for information about each plugin. If you'd like to contribute a plugin to the list, [send us a PR](https://github.com/salesforcecli/plugin-marketplace). ## 2.6.9 (Aug 30, 2023) * FIX: Salesforce CLI correctly retrieves metadata components (specifically Layouts and Profiles) whose names include non-alphanumeric characters, such as periods. (GitHub issue [#1683](https://github.com/forcedotcom/cli/issues/1683), source-deploy-retrieve PR [#1080](https://github.com/forcedotcom/source-deploy-retrieve/pull/1080)) * FIX: Salesforce DX projects now support the FundraisingConfig metadata type. ## 2.5.7 (Aug 23, 2023) * NEW: You now get a warning if you try to unset a global configuration variable without specifying the `--global` flag. The command is still considered a success because there was no local config variable to unset. For example: ```bash $ sf config list List Config ============================================= | Name Location Value | ─────────────────── ──────── ────────────── | org-max-query-limit Global 5000 | target-org Local my-scratch-org $ sf config unset org-max-query-limit Warning: The org-max-query-limit config variable is still set globally, unset it by using the --global flag. Unset Config ============================= | Name Success | ─────────────────── ─────── | org-max-query-limit true $ sf config list List Config ============================================= | Name Location Value | ─────────────────── ──────── ────────────── | org-max-query-limit Global 5000 | target-org Local my-scratch-org ``` To unset the config var, specify the `--global` flag: ```bash $ sf config unset org-max-query-limit --global Unset Config ============================= | Name Success | ─────────────────── ─────── | org-max-query-limit true $ sf config list List Config ==================================== | Name Location Value | ────────── ──────── ────────────── | target-org Local my-scratch-org ``` (plugin-settings PR [#346](https://github.com/salesforcecli/plugin-settings/pull/346)) * CHANGE: We've generally improved the human-readable output of `org list`; the JSON output remains the same. Here are some of the key improvements: * All orgs are listed in a single table, grouped by type, which is now indicated in a new column. Org types include DevHub, Scratch, and Sandbox. * The default org and DevHub are now indicated with emojis rather than the previous `(U)` and `(D)` characters which weren't intuitive. See the legend at the end of the output for what's what. * Column names are now type case rather than all-caps. Here's an example of the output: ```bash $ sf org list Type Alias Username Org ID Status Expires ── ─────── ────────────── ───────────────────────────────────────────── ────────────────── ───────────────────── ────────── 🌳 DevHub JulesDevHub jules@sf.com 00DB0001234c7jiMAA Connected Sandbox jules@sf.com.jssandtwo 00D020012344XTiEAM Connected 🍁 Scratch my-scratch-org test-qjrr9q5d13o8@example.com 00DMN0012342Gez2AE Active 2023-08-21 Legend: 🌳=Default DevHub, 🍁=Default Org Use --all to see expired and deleted scratch orgs ``` (plugin-org PR [#765](https://github.com/salesforcecli/plugin-org/pull/765)) * FIX: We've significantly shortened command startup times. Note that this performance enhancement applies to _all_ CLI commands, even ones in custom plugins. (telemetry PR [#274](https://github.com/forcedotcom/telemetry/pull/274), plugin-telemetry PR [#497](https://github.com/salesforcecli/plugin-telemetry/pull/497)) ## 2.4.8 (Aug 16, 2023) * NEW: We now provide these new TAR file formats and manifest files for installing Salesforce CLI on Linux operating systems: * [sf-linux-arm64.tar.gz](https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-linux-arm64.tar.gz) * [sf-linux-arm64.tar.xz](https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-linux-arm64.tar.xz) * [sf-linux-arm64-buildmanifest](https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-linux-arm64-buildmanifest) See [Install Salesforce CLI With a TAR File](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli_linux) for details on using the files. (The new download links will show up in the docs soon.) * NEW: Use a wildcard (`*`) with the `--metadata` flag of the deploy and retrieve commands. This example shows how to deploy all FlexiPage metadata components whose names match `Property*`: ```bash sf project deploy start --metadata "FlexiPage:Property*" --target-org myscratch ``` This sample output shows the components it deployed: ```bash Deployed Source ================================================================================================================== | State Name Type Path | ─────── ──────────────────── ───────── ───────────────────────────────────────────────────────────────────────── | Changed Property_Explorer FlexiPage force-app/main/default/flexipages/Property_Explorer.flexipage-meta.xml | Changed Property_Finder FlexiPage force-app/main/default/flexipages/Property_Finder.flexipage-meta.xml | Changed Property_Record_Page FlexiPage force-app/main/default/flexipages/Property_Record_Page.flexipage-meta.xml ``` (GitHub issue [#2386](https://github.com/forcedotcom/cli/issues/2386), source-deploy-retrieve PR [#1063](https://github.com/forcedotcom/source-deploy-retrieve/pull/1063)) * NEW: If you authorize an org that has a namespace linked, and then run `sf org list --json`, the JSON output now includes the `namespacePrefix` key, with value set to the namespace name. (GitHub issue [#1790](https://github.com/forcedotcom/cli/issues/1790), sfdx-core PR [#908](https://github.com/forcedotcom/sfdx-core/pull/908)) * CHANGE: We changed the Node.js logger that Salesforce CLI uses from Bunyan to [Pino](https://getpino.io/#/). This internal change results in these user-visible changes: * Each day's logs are written to a file whose name is based on that day. For example, the logs for August 8, 2023 are written to the file `USER_HOME_DIR/.sf/sf-2023-08-07.log`. Previously, the log were written to the `USER_HOME_DIR/.sf/sf.log` file. Each day at midnight, that log file would be rotated to `USER_HOME_DIR/.sf/sf.log.0`, and any existing log files moved up by one number. That process didn't always work correctly. * The new logger occasionally checks for, and then deletes, any log files that are older than 7 days. If you want to keep these old log files, copy them to a different location. * The new logger will never delete the `USER_HOME_DIR/.sf/sf.log` files written by the old logger. Other CLI plugins and tools, such as VS Code with the Salesforce Extension, still use the old logger and might write to these old files. At some point they will upgrade to use the new logger, but for now we still need to keep those old files around. * Here's how the log-related environment variables now work: * SF_LOG_ROTATION_PERIOD: You can set this variable to `1h` or `1m` if you want more, but smaller, log files. Any other value is treated as `1d`, which is the default. The new log file is created when the command loads. For example, if your deployment takes 40 minutes, all of its associated logs are written to a file with name based on when the command began. * SF_LOG_ROTATION_COUNT: This variable has no effect anymore. The number of logs that Salesforce CLI keeps is always 7 day's worth, regardless of how small the rotation period is. * Previously, setting `DEBUG=*` would log at the lowest level. You can now use both `DEBUG=*` and `SF_LOG_LEVEL=debug`, for example, to control how many logs you’re getting. * If you create custom CLI plugins, read more about these changes [here](https://github.com/forcedotcom/sfdx-core/blob/main/MIGRATING_V4-V5.md). (GitHub issues [#2209](https://github.com/forcedotcom/cli/issues/2209), [#2206](https://github.com/forcedotcom/cli/issues/2206), [#2198](https://github.com/forcedotcom/cli/issues/2198), [#2196](https://github.com/forcedotcom/cli/issues/2196), [#1928](https://github.com/forcedotcom/cli/issues/1928), [#1706](https://github.com/forcedotcom/cli/issues/1706), [#1699](https://github.com/forcedotcom/cli/issues/1699), [#1408](https://github.com/forcedotcom/cli/issues/1408). sfdx-core PR [#876](https://github.com/forcedotcom/sfdx-core/pull/876)) * CHANGE: These commands are generally available and no longer beta: * `schema generate sobject` * `schema generate field` * `schema generate tab` * `schema generate platformevent` (plugin-sobject [#361](https://github.com/salesforcecli/plugin-sobject/pull/361))) * CHANGE: We've updated the parent image of the [Salesforce CLI Docker images](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_docker.htm) to the [Heroku-22 stack](https://devcenter.heroku.com/articles/heroku-22-stack). (cli PR [#1028](https://github.com/salesforcecli/cli/pull/1028)) * FIX: We updated the README in this repo because it was a tad out of date. (GitHub issue [#2332](https://github.com/forcedotcom/cli/issues/2332)) * FIX: You can now successfully run `org delete sandbox` to delete a sandbox that you created in the Setup UI and then authenticated with Salesforce CLI. We've also improved the error messages around deleting a sandbox. (GitHub issues [#1718](https://github.com/forcedotcom/cli/issues/1718) and [#1667](https://github.com/forcedotcom/cli/issues/1667), sfdx-core PR [#862](https://github.com/forcedotcom/sfdx-core/pull/862), plugin-org PR [#717](https://github.com/salesforcecli/plugin-org/pull/717)) * FIX: The telemetry plugin now works correctly behind a proxy. (GitHub issue [#1752](https://github.com/forcedotcom/cli/issues/1752), telemetry PR [#268](https://github.com/forcedotcom/telemetry/pull/268)) * FIX: The SF_CONTENT_TYPE environment variable now works correctly for all Salesforce CLI commands. (GitHub issue [#2331](https://github.com/forcedotcom/cli/issues/2331), oclif/core PR [#753](https://github.com/oclif/core/pull/753)) * FIX: The `data export tree --plan` command now correctly exports the number of rows returned by the `--query` flag (up to a maximum of 2,000 rows). Previously it would sometimes export only 1,000 rows, even when the query returned more. (GitHub issue [#1663](https://github.com/forcedotcom/cli/issues/1663)) * FIX: The commands to deploy and retrieve, such as `project deploy start`, now correctly return a non-zero exit code when they fail due to a missing source file error. (GitHub issue [#2011](https://github.com/forcedotcom/cli/issues/2011), source-deploy-retrieve PR [#1062](https://github.com/forcedotcom/source-deploy-retrieve/pull/1062)) * FIX: The `package version create` command no longer deletes Profile `fieldPermissions` on custom fields of the Activity object. (GitHub issue [#2278](https://github.com/forcedotcom/cli/issues/2278), packaging PR [#348](https://github.com/forcedotcom/packaging/pull/348)) ## 2.3.8 (Aug 9, 2023) * NEW: When you install an unsigned plugin with the `sf plugins install` command, and you answer Y to the warning, you now get information about adding the plugin to the `unsignedPluginAllowList.json` allow list file, and a link to the docs for more information. (plugin-trust PR [#545](https://github.com/salesforcecli/plugin-trust/pull/545)) * FIX: Salesforce DX projects now support these metadata types: * SearchCriteriaConfiguration * SearchableObjDataSyncInfo ## 2.2.7 (Aug 2, 2023) * FIX: The `package install` command now uses a reasonable number of API calls when it polls for installation status. As a result, the performance of the command has improved and fewer writes are made to the log file. (GitHub issue [#2319](https://github.com/forcedotcom/cli/issues/2319), packaging PR [#355](https://github.com/forcedotcom/packaging/pull/355)) * FIX: The `apex run test` command now correctly honors the `--output-dir` flag. (GitHub issue [#2321](https://github.com/forcedotcom/cli/issues/2321), plugin-apex PR [#178](https://github.com/salesforcecli/plugin-apex/pull/178)) * FIX: We've reduced the amount of time between the end of a deployment to the target org (such as with the `project deploy start` command) and when the command itself exits. (GitHub issue [#2012](https://github.com/forcedotcom/cli/issues/2012), source-tracking PR [#446](https://github.com/forcedotcom/source-tracking/pull/446)) * FIX: Salesforce DX projects now support the MessagingChannel metadata type. * FIX: Really large retrieves won't throw a `Maximum call stack size exceeded` anymore. SDR PR [#1046](https://github.com/forcedotcom/source-deploy-retrieve/pull/1046) * FIX: When retrieving a CustomObject (including CustomMetadataTypes), the top-level `Whatever__c.object-meta.xml` will no longer be saved to your project when it's ignored by `.forceignore`. SDR PR [#1053](https://github.com/forcedotcom/source-deploy-retrieve/pull/1053) ## 2.1.7 (July 26, 2023) * NEW: View the package name and version when you run `package version create list` with the new `--verbose` flag. The information is displayed in both the human-readable table and JSON results. For example: ```bash sf package version create list --created-last-days 3 --target-dev-hub --verbose ``` (GitHub issue [#222](https://github.com/forcedotcom/cli/issues/222), plugin-packaging PR [#370](https://github.com/salesforcecli/plugin-packaging/pull/370)) * NEW: Specify test formats and destructive changes for the `project deploy validate` command with these new flags: * `--coverage-formatters` : Format of the code coverage results. * `--junit` : Output JUnit test results. * `--results-dir` : Output directory for code coverage and JUnit results; defaults to the deploy ID. * `--post-destructive-changes` : File path for a manifest (destructiveChangesPost.xml) of components to delete after the deploy. * `--pre-destructive-changes` : File path for a manifest (destructiveChangesPre.xml) of components to delete before the deploy * `--purge-on-delete` : Specify that deleted components in the destructive changes manifest file are immediately eligible for deletion rather than being stored in the Recycle Bin. These flags already exist on the `project deploy start` command; use them in the same way when validating a deployment. For example: ```bash sf project deploy validate --source-dir path/to/source --test-level RunAllTestsInOrg --junit --results-dir results --post-destructive-changes path/to/destructiveChangesPost.xml ``` (GitHub issues [#2265](https://github.com/forcedotcom/cli/issues/2265) and [#2255](https://github.com/forcedotcom/cli/issues/2255) and [#2246](https://github.com/forcedotcom/cli/issues/2246), plugin-deploy-retrieve PR [#675](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/675)) * NEW: The JSON output of the `sf project deploy validate --json` command now contains a `deployId` property, which is useful if the validation fails and you want the ID to figure out the problem. The ID is in the new `data` property of the JSON output. For example: ```json { "code": 1, "context": "DeployMetadataValidate", "commandName": "DeployMetadataValidate", "data": { "deployId": "0Af1nFakeID123" }, "message": "Failed to validate the deployment (0Af1nFakeID123).", "name": "FailedValidationError", ... ``` (GitHub issue [#2312](https://github.com/forcedotcom/cli/issues/2312), plugin-deploy-retrieve PR [#702](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/702)) * NEW: Easily determine which records failed to bulk upsert or delete by specifying the new `--verbose` flag of the `sf data upsert|delete bulk` commands. If one or more records fail to bulk upsert or delete, the command displays a table with the record IDs and error. Thank you, [Robin Windey](https://github.com/R0Wi), for the great idea, and then contributing the code. We love it. And this is your second contribution, which is awesome. Are you planning a third? We hope so! (GitHub issue [#2221](https://github.com/forcedotcom/cli/issues/2221), plugin-data PR [#615](https://github.com/salesforcecli/plugin-data/pull/615)) * CHANGE: Previously, when deploying metadata, Salesforce CLI allowed you to include multiple files with identical file paths in the ZIP file that's sent to the org to deploy, and the org would deploy them. Crazy, huh. We recently swapped out a library to fix a different issue, and the new library no longer supports that incorrect behavior. (GitHub issue [#2191](https://github.com/forcedotcom/cli/issues/2191)) * FIX: Salesforce CLI now detects when you include the word `help` in a command and asks if you're looking for help information about the rest of the command. For example, if you type `sf package install help`, the CLI asks if you want help about `package install`. (GitHub issue [#2240](https://github.com/forcedotcom/cli/issues/2240), oclif PR [#409](https://github.com/oclif/plugin-not-found/pull/409)) * FIX: If you run `project deploy report --results-dir`, the command now uses the new results directory rather than the one from the original `project deploy start` command, if specified. (GitHub issue [#2265](https://github.com/forcedotcom/cli/issues/2265), plugin-deploy-retrieve PR [#675](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/675)) * FIX: You can now run `project deploy validate --metdata-dir` outside of a Salesforce DX project. (GitHub issue [#2275](https://github.com/forcedotcom/cli/issues/2275), plugin-deploy-retrieve PR [#691](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/691)) * FIX: Deploy and retrieves when running the `project deploy|retrieve` commands now correctly show the progress bar by default. (GitHub issues [2276](https://github.com/forcedotcom/cli/issues/2276) and [2249](https://github.com/forcedotcom/cli/issues/2249), plugin-deploy-retrieve PR [#681](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/681) * FIX: The `project retrieve` command now clearly displays the API version it's using for the HTTP request/response (`apiVersion`) and the metadata shape (`sourceApiVersion`). See [How API Version and Source API Version Work in Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_apiversion.htm) for more information. (GitHub issue [#353](https://github.com/forcedotcom/cli/issues/353), plugin-deploy-retrieve [#669](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/669)) * FIX: We now display the help for partial commands if Salesforce CLI finds only one possible match. For example, `sf project create --help` correctly displays the help for `project generate` because it's the only (aliased) match. Previously you'd get a `Command not found.` error. (GitHub issue [#2301](https://github.com/forcedotcom/cli/issues/2301), oclif PR [#733](https://github.com/oclif/core/pull/733)) * FIX: `package:version:create` no longer remove Profiles just because they are empty. (GitHub issues [#2192](https://github.com/forcedotcom/cli/issues/2192)/[#2218](https://github.com/forcedotcom/cli/issues/2218) , packaging PR [#349](https://github.com/forcedotcom/packaging/pull/349)) * FIX: `package:version:create` was briefly erroring because of a change in the xml2js library. They fixed it and that fixed these commands. If you encounter the issue, uninstall the packaging plugin and run your command again to get the new fixed version. (GitHub issue [#2324](https://github.com/forcedotcom/cli/issues/2324)). * FIX: Salesforce DX projects now support these metadata types: * ExtlClntAppMobileConfigurablePolicies * ExtlClntAppMobileSettings * ServiceProcess * ProcessFlowMigration ## 2.0.2 (July 19, 2023) Welcome to the GA of `sf` (v2)! Check out [this blog post](https://developer.salesforce.com/blogs/2023/07/salesforce-cli-sf-v2-is-here) for information about this new Salesforce CLI version. We recommend that you start using the `sf`-style CLI commands soon, such as `sf org create scratch`. Don't worry, the `sfdx`-style commands continue to work just fine, such as `sfdx force:org:create`. But we think you'll like the new ones better. See [this document](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_migrate.htm) for migration information. We're in the process of updating the [Salesforce DX Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm) to show `sf`-style examples and usage. We hope you enjoy `sf` (v2)! And now on to our regular ole release notes. ---------------------------------------------------- * FIX: When you run `org delete scratch | sandbox` to delete your default org, the CLI now also unsets the `target-org` configuration variable (if set) and any aliases which point to the deleted org. (sfdx-core PR [#874](https://github.com/forcedotcom/sfdx-core/pull/874)) * FIX: The `package version create` command now correctly displays an error if the `definitionFile` parameter of `packageDirectories` in the `sfdx-project.json` file is set to an incorrect file location. Previously the command would fail silently. (GitHub issue [#2193](https://github.com/forcedotcom/cli/issues/2193), plugin-packaging PR [#364](https://github.com/salesforcecli/plugin-packaging/pull/364)) ================================================ FILE: releasenotes/sf/README.md ================================================ # Salesforce CLI Release Notes (sf Commands) **IMPORTANT ANNOUNCEMENT, PLEASE READ**: We no longer update `sf` (v1); the last stable version is `1.86.6`. The current release is now `sf` (v2); read the release notes [here](../README.md). See [this note](./README.md#1866-july-12-2023-stable) for additional details. --- Here are the new and changed features in recent updates of the `sf` executable of Salesforce CLI. We publish a new stable version of `sf` on Wednesday. At the same time we also publish an `sf` release candidate that contains changes that we plan to include in next week's `sf` release. Run `sf version` to display the version of `sf` installed on your computer. **Installation**: If you installed Salesforce CLI with the `sfdx` [installers](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm), then `sf` is also installed automatically. If you installed `sfdx` via `npm` then you must install `sf` separately by running `npm install @salesforce/cli -g`. **Update**: If you installed `sf` with the `sfdx` installers, run `sfdx update` to update to the latest available stable version. Run `sfdx update stable-rc` to update to the release candidate. To return to the stable version, run `sfdx update stable`. If you installed `sf` with `npm`, run `npm install @salesforce/cli@latest-rc -g` to update to the release candidate. To return to the stable version, run `npm install @salesforce/cli@latest -g`. [Click here for the release notes for the `sfdx` executable.](../sfdx/README.md) Additional documentation: * [Salesforce CLI Command Reference (sf)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_unified.htm) * [Get Started with Salesforce CLI Unification](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_sf_intro.htm) * [Salesforce CLI Plugin Developer Guide (sf)](https://github.com/salesforcecli/cli/wiki/Quick-Introduction-to-Developing-sf-Plugins) * [Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm) ## 1.86.6 (July 12, 2023) [stable] **IMPORTANT ANNOUNCEMENT, PLEASE READ**: We no longer update `sf` (v1); the last stable version is `1.86.6`. You can keep using `sf` (v1) if you want, but it won't contain new features or bug fixes. And we no longer update this page. To continue getting weekly CLI updates, you must move to `sf` (v2). * If you installed `sf` (v1) with `npm`, just update as usual: `npm install @salesforce/cli --global`. * If you installed `sf` (v1) using the `sfdx` installers (which bundled `sf` (v1)), uninstall `sfdx` and then install `sf`. See the new [Move from `sfdx` (v7) to `sf` (v2)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_move_to_sf_v2.htm) section of the Setup Guide for details, including how to update your continuous integration (CI) scripts. We also updated the entire Setup Guide to assume you're using `sf` (v2) and the `sf`-style CLI commands and configuration. The `sf` (v2) Release Notes are [here](../README.md); start checking that page for information about our weekly Salesforce CLI releases. For context and information about this change, see [this blog post](https://developer.salesforce.com/blogs/2023/07/salesforce-cli-sf-v2-is-here). -------------------------------------------- -------------------------------------------- * FIX: When you run `org delete scratch | sandbox` to delete your default org, the CLI now also unsets the `target-org` configuration variable (if set) and any aliases which point to the deleted org. (sfdx-core PR [#874](https://github.com/forcedotcom/sfdx-core/pull/874)) * FIX: The `pacakge version create` command now correctly displays an error if the `definitionFile` parameter of `packageDirectories` in the `sfdx-project.json` file is set to an incorrect file location. Previously the command would fail silently. (GitHub issue [#2193](https://github.com/forcedotcom/cli/issues/2193), plugin-packaging PR [#364](https://github.com/salesforcecli/plugin-packaging/pull/364)) ## 1.85.8 (July 5, 2023) ANNOUNCEMENTS: * Check out `sf` (v2), which is now in Beta! See our [Trailblazer announcement](https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000Pf2wKSAR) for more information. * If you install Salesforce CLI using `npm`, and use Node.js 14 or 16, be aware of these [end-of-life dates](https://github.com/forcedotcom/cli/issues/1985). -------------------------------------------- * NEW: Specify the value of the `sourceApiVersion` property in the generated `sfdx-project.json` project file with the new `--api-version` flag of the `project generate` command. The flag value overrides the `org-api-version` configuration variable, if set. If neither the flag nor the config var is set, then the `sourceApiVersion` property is set to the default value. For example: ```bash sf project generate --name myFabProject --api-version 58.0 ``` (GitHub issue [#1939](https://github.com/forcedotcom/cli/issues/1939), plugin-templates PR [#150](https://github.com/salesforcecli/plugin-templates/pull/150)) * NEW: Include deleted records and archived activities when you run a SOQL query with the `data query` command by specifying the new `--all-rows` Boolean flag. This feature is equivalent to using the [ALL ROWS keyword when executing a SOQL query from Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_query_all_rows.htm). For example: ```bash sf data query --query "SELECT Id, Name, Account.Name FROM Contact" --all-rows ``` (GitHub issue [#1959](https://github.com/forcedotcom/cli/issues/1959), plugin-data PR [#602](https://github.com/salesforcecli/plugin-data/pull/602)) * NEW: When using the [pre-deployment string replacement feature](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_string_replace.htm), you can now specify that if an environment variable isn’t set, then _remove_ a string from the source file. Use the new `allowUnsetEnvVariable` property together with the `replaceWithEnv` property in the `replacements` section of your `sfdx-project.json` file. In this example, if the environment variable SOME_ENV_THAT_CAN_BE_BLANK isn’t set, the string `myNS__` in the `myClass.cls` file is removed when the file is deployed. If the environment variable is set to a value, then that value replaces the `myNS__` string. ```json "replacements": [ { "filename": "/force-app/main/default/classes/myClass.cls", "stringToReplace": "myNS__", "replaceWithEnv": "SOME_ENV_THAT_CAN_BE_BLANK", "allowUnsetEnvVariable": true } ] ``` (GitHub issue [#2070](https://github.com/forcedotcom/cli/issues/2070), source-deploy-retrieve PR [#1019](https://github.com/forcedotcom/source-deploy-retrieve/pull/1019)) * FIX: We no longer display `Unexpected end of JSON input` when you run `org list` and one of your org authorization files is corrupt. We now display information for all orgs whose authorization files are fine, and a warning about the org that has the corrupt auth file. You can then delete the corrupt file and reauthorize the org. (GitHub issue [#2066](https://github.com/forcedotcom/cli/issues/2066), sfdx-core PR [#869](https://github.com/forcedotcom/sfdx-core/pull/869)) * FIX: We now provide a better error message if your `.forceignore` file includes only one of the two source files for MetadataWithContent metadata types and you try to deploy or retrieve the type. For example, the `MyClass` Apex class consist of two source files: `MyClass.cls` and `MyClass.cls-meta.xml`. If you want to ignore the `MyClass` Apex class, you must list both these files (or use an asterisk) in your `.forceignore` file. (GitHub issue [#2237](https://github.com/forcedotcom/cli/issues/2237), source-deploy-retrieve PR [#1020](https://github.com/forcedotcom/source-deploy-retrieve/pull/1020)) * FIX: Source tracking now correctly handles metadata type names that contain special characters, such as parentheses. (GitHub issue [#2212](https://github.com/forcedotcom/cli/issues/2212), source-tracking PR [#421](https://github.com/forcedotcom/source-tracking/pull/421)) * FIX: You can now set the `--instance-url` flag to a value that includes the `lightning` string as long as it's part of your actual My Domain name. For example, `https://mycompanyname-lightning.my.salesforce.com` is valid because the My Domain name itself includes `-lightning`. But we continue to not allow Lightning domain instance URLs, such as `https://mydomain.lightning.force.com`. (GitHub issue [#2241](https://github.com/forcedotcom/cli/issues/2241), plugin-auth PR [#732](https://github.com/salesforcecli/plugin-auth/pull/732)) * FIX: When a bulk data command, such as `data delete bulk`, fails, we now return an exit code of 1. Previously we incorrectly returned an exit code of 0. (GitHub issue [#1648](https://github.com/forcedotcom/cli/issues/1648), plugin-data PR [#601](https://github.com/salesforcecli/plugin-data/pull/601)) * FIX: Salesforce DX projects now support these metadata types: - ExtlClntAppSampleConfigurablePolicies (previously called ExtlClntAppMobileConfigurablePolicies) - ExtlClntAppSampleSettings (previously called ExtlClntAppMobileSettings) ## 1.84.7 (June 28, 2023) * NEW: Are you ready to convert your CI scripts to start using the `sf`-style commands? For example, you want to start using `org create scratch` to create a scratch org rather than `force:org:create`. If you're ready, use our new `dev convert script` command to convert most, if not all, of a script. First install the `plugin-dev` plugin. ```bash sf plugins install @salesforce/plugin-dev ``` Then pass your script file to the `dev convert script` command with the `--script` flag. ```bash sf dev convert script --script ./myScript.yml ``` The command scans your script file; when it finds an `sfdx` command or flag, it prompts whether you want to replace it with the new `sf` equivalent. Don't worry, the command doesn’t change your original file; instead it creates a file with the replacements, such as `myScript-converted.yml`. There's not always a one-to-one mapping between the `sfdx` and `sf` commands. As a result, `dev convert script` can convert a large portion of your script, but it likely can’t convert _all_ of it. In these cases, the command doesn't replace the `sfdx` command but instead adds a comment that starts with `#ERROR`. Finally, remember to test the converted script to make sure it's working as you expect! And check out the new [migration topics](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_migrate.htm) in the Salesforce CLI Reference Guide. * NEW: Run specific Apex tests when run `project delete source` with the new `RunSpecifiedTests` value of the `--test-level` flag. Just like the `project deploy start` command, specify the tests with the new `--tests` flag. Previously you were required to run either all local or org tests. For example: ```bash sf project delete source --metadata ApexClass:ExcitingClass --test-level RunSpecifiedTests --tests ApexClass:TestExcitingClass --target-org myorg ``` (GitHub issue [#2175](https://github.com/forcedotcom/cli/issues/2175), plugin-deploy-retrieve [#659](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/659)) * FIX: We now display a message with useful information when `org create scratch` fails due to a problem in the `settings` in the definition file. (GitHub issue [#2227](https://github.com/forcedotcom/cli/issues/2227), [sfdx-core](https://github.com/forcedotcom/sfdx-core/commit/39d1124804ee845533888878c9a7aeb2c0ed8c25)) * FIX: If you pass a config variable with a typo to `config unset`, the command asks if you meant the var with the correct spelling. If you answer `Y`, and the command is successful, it no longer displays the `Unknown config name` error. (GitHub issue [2019](https://github.com/forcedotcom/cli/issues/2019), plugin-settings PR [#291](https://github.com/salesforcecli/plugin-settings/pull/291)) * FIX: We reverted to the previous release of [`isomorphic-git`](https://isomorphic-git.org/) (a Salesforce CLI dependency) due to issues in version `1.24.0`. (GitHub issue [#2194](https://github.com/forcedotcom/cli/issues/2194), source-tracking PR [#417](https://github.com/forcedotcom/source-tracking/pull/417)) ## 1.83.6 (June 21, 2023) * CHANGE: We've removed all the `beta` aliases for the `force package` and `force package1` commands. As a result, you can no longer run commands like `force package beta version create`; use `package version create` instead. (plugin-packaging PR [#356](https://github.com/salesforcecli/plugin-packaging/pull/356)) * FIX: Running `project deploy start` with the environment variable `SF_USE_PROGRESS_BAR=false` now produces the expected output, similar to how the `force:source:deploy` worked. Specifically, the output doesn't include the bar graphics, it does include test completion and errors, and the output goes to stderr. (GitHub issue [#2103](https://github.com/forcedotcom/cli/issues/2103), plugin-deploy-retrieve PR [#662](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/662)) * FIX: When the `project deploy start` command fails, the output now wraps if your terminal is too narrow; previously the information was truncated. (GitHub issue [#2048](https://github.com/forcedotcom/cli/issues/2048 ), plugin-deploy-retrieve PR [#654](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/654)) * FIX: The `project retrieve start --package-name ` now retrieves only the specified package, and not the `unpackaged` package. (GitHub issue [#2148](https://github.com/forcedotcom/cli/issues/2148), plugin-deploy-retrieve PR [#658](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/658)) * FIX: Tables in command output are no longer truncated by default. As a result, when you run `org display --verbose`, for example, you now see the entire Access Token and Sfdx Auth Url values. (GitHub issue [#1974](https://github.com/forcedotcom/cli/issues/1974), sf-plugins-core PR [#318](https://github.com/salesforcecli/sf-plugins-core/pull/318)) * FIX: The `project retrieve start` command now correctly ignores files in non-default package directories if the files are listed in the `.forceignore` file. (GitHub issue [#2126](https://github.com/forcedotcom/cli/issues/2126), plugin-deploy-retrieve PR [#652](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/652), source-tracking PR [#412](https://github.com/forcedotcom/source-tracking/pull/412)) * FIX: Let's say you run `project deploy start --dry-run --metadata-dir` to validate a deploy of files in metadata format. You can now run `project deploy quick` on the validated job without errors. (GitHub issue [#2098](https://github.com/forcedotcom/cli/issues/2098), plugin-deploy-retrieve PR [#651](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/651)) * FIX: When you run `project deploy start|validate` and it fails due to insufficient code coverage, you now get a warning; previously it failed without explanation. (GitHub issue [#2179](https://github.com/forcedotcom/cli/issues/2179), plugin-deploy-retrieve PR [#656](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/656)) ## 1.82.6 (June 14, 2023) * NEW: Use the new `jobId` value to check the status of your Experience Cloud site during the site creation or site publish process. The site creation and site publish processes are async jobs that generate a `jobId`. When you run `community create` or `community publish`, we include the `jobId` in the command results. To check the status of your site creation or site publish job, query the BackgroundOperation object and enter the `jobId` as the Id. Experience Cloud site IDs start with `08P`. For example, if you ran the `community create` command on an org with alias `community`, use this command to query its status (replace `08Pxxx` with your specific `jobID`): ```bash sf data query --query "SELECT Status FROM BackgroundOperation WHERE Id = '08Pxxx'" --target-org community ``` Completed site creation and site publish jobs expire after 24 hours and are removed from the database. (plugin-community PR [#353](https://github.com/salesforcecli/plugin-community/pull/353)) * FIX: We've fixed a number of issues related to Node.js v18.16.0. If you followed [our suggestions](https://github.com/forcedotcom/cli/issues/2125) for working around the issues, you can now return to the version of Node.js you were using before and update Salesforce CLI to the latest version. (GitHub issue [#2125](https://github.com/forcedotcom/cli/issues/2125), source-deploy-retrieve PR [#975](https://github.com/forcedotcom/source-deploy-retrieve/pull/975)) * FIX: The `project` commands that have the `-x|--manifest` flag, such as `project convert source` or `project deploy start`, correctly return an error if the specified manifest XML file is invalid. When possible, the commands also display information about what makes the file invalid. Previously the commands silently ignored the component with the invalid XML and incorrectly displayed a successful result. (source-deploy-retrieve PR [#996](https://github.com/forcedotcom/source-deploy-retrieve/pull/996)) * FIX: Running multiple commands that set an alias in parallel, such as `org create scratch --alias`, now correctly set the aliases for all the commands. Previously only one alias would be set. (GitHub issues [#1810](https://github.com/forcedotcom/cli/issues/1810) and [#1806](https://github.com/forcedotcom/cli/issues/1806), sfdx-core PR [#842](https://github.com/forcedotcom/sfdx-core/pull/842)) * FIX: When running `project deploy start` with the `--json` flag, you can now also use the `--junit` and `--coverage-formatters` flags to output JUnit local test results. Previously the results weren't created if you specified `--json`. (GitHub issue [#2172](https://github.com/forcedotcom/cli/issues/2172), plugin-deploy-retrieve PR [#650](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/650)) * FIX: You can now successfully add a sibling sub-topic with the `dev generate command` command. Previously, if you tried to add a sibling topic when one already existed in the plugin, the first topic was overwritten in the plugin's `package.json` file. Now all works as expected and life is good again. (GitHub issue [#1805](https://github.com/forcedotcom/cli/issues/1805), plugin-dev PR [#335](https://github.com/salesforcecli/plugin-dev/pull/335)) Many thanks to [KevinGossentCap](https://github.com/KevinGossentCap) for contributing the fix! We love it. * FIX: When you run `package version create|update`, Salesforce CLI now resolves dependencies using the `branch` attribute of the `dependencies` key in the `sfdx-project.json` file and not the value of the `--branch` flag, if both are set. The value of the `--branch` flag is used only if the `branch` attribute isn't specified in `sfdx-project.json`. (GitHub issue [#2183](https://github.com/forcedotcom/cli/issues/2183), packaging PR [#310](https://github.com/forcedotcom/packaging/pull/310)) Woo-hoos and thanks to [David Polehonski](https://github.com/David-Polehonski) for finding the issue, and then contributing the fix. We love this one too. ## 1.81.6 (June 7, 2023) * FIX: Get JSON output from the `sf plugins` command with the new `--json` flag. (GitHub issue [#267]( https://github.com/forcedotcom/cli/issues/267), oclif plugin-plugin PR [#609](https://github.com/oclif/plugin-plugins/pull/609)) * FIX: The `cmdt generate records` command correctly handles spaces and other non-alphanumeric characters in the CSV file when generating custom metadata type records. (GitHub issue [#2158](https://github.com/forcedotcom/cli/issues/2158), plugin-custom-metadata PR [#481](https://github.com/salesforcecli/plugin-custom-metadata/pull/481)) * FIX: The `project deploy start` command no longer return the error `Cannot read properties of null (reading 'replace')` when Apex tests fail. (GitHub issue [#2149](https://github.com/forcedotcom/cli/issues/2149), plugin-deploy-retrieve PR [#633](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/633)) * FIX: The `project deploy start` command now displays metadata component failures in its command-line output. (GitHub issue [#2008](https://github.com/forcedotcom/cli/issues/2008), plugin-deploy-retrieve PR [#623](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/623)) ## 1.80.6 (May 31, 2023) * NEW: We now group the multiple flags of `project deploy|retrieve start` and `org create scratch` in the `-h|--help` output so you can easily find that special flag you love so much. For example, we group the testing flags of `project deploy start` under TEST FLAGS. For `org create scratch`, we group the flags that override options in the scratch org definition file under DEFINITION FILE OVERRIDE FLAGS. (plugin-deploy-retrieve PR [#626](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/626), plugin-org [#685](https://github.com/salesforcecli/plugin-org/pull/685)) * NEW: Retrieve source files from your org into a directory other than the defined package directories with the new `--output-dir` (`-r`) flag of `project retrieve start`. If the output directory matches one of the package directories in your `sfdx-project.json` file, the command fails. (plugin-deploy-retrieve PR [#627](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/627)) * NEW: Salesforce DX projects now support the ScoreCategory metadata type. * FIX: You can now generate a custom field of type `Number` on an object using the `schema generate field` command. (GitHub issue [#2142](https://github.com/forcedotcom/cli/issues/2142), plugin-sobject PR [#292](https://github.com/salesforcecli/plugin-sobject/pull/292)) * FIX: The description for the `--test-level` flag of the `project deploy start|validate` commands in their `--help` correctly refers to the `--tests` flag; previously it mentioned the non-existent `--run-tests` flag. (GitHub issue [#2117](https://github.com/forcedotcom/cli/issues/2117), plugin-deploy-retrieve PR [#622](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/622)) * FIX: Deleting a single custom label component with the `project source delete` command, or with one of the destructive changes flags of `project deploy start` command, no longer deletes the entire `CustomLabels.labels-meta.xml` file. (GitHub issue [#2118](https://github.com/forcedotcom/cli/issues/2118), plugin-deploy-retrieve PR [#613](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/613)) ## 1.79.0 (May 24, 2023) * NEW: You can now specify these two scratch org definition file options as command-line flags when you run `org create scratch`: * `--admin-email`: Email address that's applied to the org's admin user. Equivalent to the `adminEmail` option in the scratch org definition file. * `--source-org`: 15-character ID of the org whose shape the new scratch org is based on. Equivalent to the `sourceOrg` option in the scratch org definition file. As always, if you set the option in the scratch org definition file, and also specify its equivalent flag, the flag overrides the defintion file setting. For example, let's say you set `adminEmail` in the scratch org definition file to `milo@tollbooth.com`. When you run this command, however, the scratch org admin's email address is actually set to `tock@phantom.com`: ```bash sf org create scratch --definition-file config/project-scratch-def.json --admin-email tock@phantom.com --target-dev-hub DevHub ``` (GitHub Feature Request [#2130](https://github.com/forcedotcom/cli/issues/2130), plugin-org PR [#681](https://github.com/salesforcecli/plugin-org/pull/681)) * NEW: Salesforce DX projects now support the UserAccessPolicy metadata type. * CHANGE: the `project deploy` commands now leave the `--test-level` flag undefined by default and let the org decide what tests run. If you don't specify the flag: - Non-production orgs don't run any tests. - Production orgs run tests if the deployment includes Apex classes or triggers. * FIX: We cleaned up the `--help` for the `project deploy start` command around specifying multiple Apex tests or code coverage formats with the `--tests` and `--coverage-formatters` flags. You no longer use a comma-separated list; instead, specify the flags multiple times or separate the values with spaces. (GitHub issue [#2117](https://github.com/forcedotcom/cli/issues/2117), plugin-deploy-retrieve PRs [#609](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/609) and [#662](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/622)) * FIX: We updated the `--help` for `org logout` to clarify that you don't get a list of orgs to interactively log out of if you've set your default org in your environment, such as with the `target-org` config variable. (GitHub issue [#2128](https://github.com/forcedotcom/cli/issues/2128), plugin-auth PR [#696](https://github.com/salesforcecli/plugin-auth/pull/696)) * FIX: The `orgID` value in the JSON output resulting from running `sf org create scratch --json` now contains the actual scratch org ID (starts with 00D) rather than the ScratchOrgInfo record ID (starts with 2SR). (GitHub issue [#2131](https://github.com/forcedotcom/cli/issues/2131), plugin-org PR [#675](https://github.com/salesforcecli/plugin-org/pull/675)) * FIX: All commands now know about the `org-metadata-rest-deploy` configuration variable, which is the new `sf`-style name for the `restDeploy` configuration variable. (GitHub issue [#2127](https://github.com/forcedotcom/cli/issues/2127), sfdx-core PR [#834](https://github.com/forcedotcom/sfdx-core/pull/834), plugin-signups PR [#276](https://github.com/salesforcecli/plugin-signups/pull/276)) * FIX: You can now run `project deploy start --metadata-dir`, which deploys source in metadata format, from outside a Salesforce DX project. Similarly, `project retrieve start --target-metadata-dir` also works outside of a project. (GitHub issue [#2089](https://github.com/forcedotcom/cli/issues/2089), plugin-deploy-retrieve PR [#619](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/619)). * FIX: You can now run `project retrieve start --package-name` on an org that doesn't have source-tracking enabled. (GitHub issue [#2091](https://github.com/forcedotcom/cli/issues/2091), plugin-deploy-retrieve PR [#619](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/619)) * FIX: When you run `project deploy start` without any of the flags that specify exactly what you want to deploy (such as `--source-dir`, `--manifest`, or `--metadata`), and nothing is deployed, the command now exits with a `0` code. Previously it exited with a `1` code. (GitHub discussion [#2065](https://github.com/forcedotcom/cli/discussions/2065), plugin-deploy-retrieve PR [#619](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/619)) ## 1.78.0 (May 17, 2023) * NEW: Autocomplete now works on Windows [PowerShell](https://learn.microsoft.com/en-us/powershell/)! Partially type a Salesforce CLI command or flag, then press Tab to see all the available commands or flags. Install the feature with these steps: 1. From a PowerShell window, run `sf autocomplete powershell`. 2. Follow the displayed instructions. 3. If autocomplete doesn’t work immediately after installation, run `sf autocomplete --refresh-cache`. Then open a new PowerShell window. Your work-life on Windows just got a little easier, how great is that? * NEW: When the `project generate manifest` command runs into an unknown metadata type, such as from a misspelled metadata file, the error now includes handy suggestions for one or more similar metadata types that the command _does_ know about. (source-deploy-retrieve PR [#948](https://github.com/forcedotcom/source-deploy-retrieve/pull/948)) * FIX: The `project deploy|retrieve start` commands now support these metadata types: * AIScoringModelDefinition * AIScoringModelDefVersion * SkillType * FIX: The JUnit test results after a successful execution of `project deploy start --junit` no longer include an empty failure tag. Many thanks to [Robin Windey](https://github.com/R0Wi) who contributed the fix. We love it, and hope to see more from you and the community! (GitHub issue [#2076](https://github.com/forcedotcom/cli/issues/2076), plugin-deploy-retrieve PR [#610](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/610)) * FIX: If a deploy or retrieve encounters a `Socket connection timeout` error, the command now keeps retrying the deploy up to the retry limit. (GitHub issue [#2086](https://github.com/forcedotcom/cli/issues/2086), source-deploy-retrieve PR [#957](https://github.com/forcedotcom/source-deploy-retrieve/pull/957)) * FIX: We've improved the error message when you specify an invalid value for a flag of type `duration`, such as the `--wait` flag of `project deploy start`. (GitHub issue [#2109](https://github.com/forcedotcom/cli/issues/2109), sf-plugins-core PR [#287](https://github.com/salesforcecli/sf-plugins-core/pull/287)) * FIX: The `apex test run` command now correctly returns an error if you pass `-1` to its `--wait` flag. Previously the command would ignore the value and wait for the default 1 minute. The minimum value for this flag is `0`. (GitHub issue [#2110](https://github.com/forcedotcom/cli/issues/2110), plugin-apex PR [#116](https://github.com/salesforcecli/plugin-apex/pull/116)) * FIX: The `--license-type` flag of `org create sandbox` is now playing nice. In particular, its default value doesn't override the `licenseType` setting in the sandbox definition type when you don't specify the flag. And you no longer get an error when you specify both the flag and the `licenseType` definition file option. (GitHub issue [#2026](https://github.com/forcedotcom/cli/issues/2026), plugin-org [#667](https://github.com/salesforcecli/plugin-org/pull/667)) * FIX: String replacements before deploying metadata to the org are now working consistently on Windows, regardless of the shell you use. Special thanks to [micha79x](https://github.com/micha79x) for an excellent repo that reproduced the problem, and for doing most of the detective work. (GitHub issue [#1885](https://github.com/forcedotcom/cli/issues/1885), source-deploy-retrieve PR [#958](https://github.com/forcedotcom/source-deploy-retrieve/pull/958)) * FIX: The `dev generate command` and `dev generate field` commands now work correctly on Windows. (GitHub issue [#2051](https://github.com/forcedotcom/cli/issues/2051), plugin-dev PR [#317](https://github.com/salesforcecli/plugin-dev/pull/317)) ## 1.77.6 (May 10, 2023) * CHANGE: After you run `org login web` and log into your org, you're now redirected to a web page that displays either success or failure, depending on whether you were able to log in successfully. You're no longer redirected to Salesforce's [frontdoor.jsp page](https://help.salesforce.com/s/articleView?id=sf.security_frontdoorjsp.htm&type=5). (sfdx-core PR [#811](https://github.com/forcedotcom/sfdx-core/pull/811)) * FIX: We fixed the `directoryName` property for these two metadata types (associated with OAuth and mobile policies) in Salesforce CLI's metadata registry: ExtlClntAppOauthConfigurablePolicies and ExtlClntAppMobileConfigurablePolicies. (SDR PR [#947](https://github.com/forcedotcom/source-deploy-retrieve/pull/947)) * FIX: When you install a Salesforce CLI plugin, the CLI now validates that the package name is a valid npm package. This validation prevents accidents and increases security. (GitHub issue [#594](https://github.com/oclif/plugin-plugins/issues/594), oclif plugin-plugin PR [#597](https://github.com/oclif/plugin-plugins/pull/597)) * FIX: We've added a warning when you run `force:org:create` to say that it's been replaced by these two commands: `org create scratch` or `org create sandbox`. (plugin-org PR [#668](https://github.com/salesforcecli/plugin-org/pull/668)) * FIX: The `package1 version list` command now displays all results, not just the first 2000. (GitHub issue [#2073](https://github.com/forcedotcom/cli/issues/2073), packaging PR [#277](https://github.com/forcedotcom/packaging/pull/277)) ## 1.76.2 (May 3, 2023) * FIX: Salesforce CLI no longer creates massive log files when certain criteria are met. (GitHub issues [#1942](https://github.com/forcedotcom/cli/issues/1942) and [#1408](https://github.com/forcedotcom/cli/issues/1408), sfdx-core PR [#818](https://github.com/forcedotcom/sfdx-core/pull/818)) ## 1.75.0 (April 26, 2023) * NEW: When you create a scratch org with `org create scratch`, you specify a definition file that contains options or use the` --edition` flag to specify the one required option. For either method, you can now also use these flags; if you use them with `--definition-file`, they override their equivalent option in the scratch org definition file: * `--description` * `--name` (equivalent to the `orgName` option) * `--username` * `--release` * `--edition` Note that now you can use `--definition-file` and `--edition` in a single command; previously you had to pick one or the other. If you want to set options other than the preceding ones, such as org features or settings, you must use a definition file. In this example, the command uses a scratch org definition file but overrides its `edition` and `description` options: ```bash sf org create scratch --definition-file config/project-scratch-def.json --edition enterprise --description "Enterprise Edition scratch org" --target-dev-hub DevHub --set-default ``` In this example, the command specifies all the options at the command line: ```bash sf org create scratch --edition enterprise --description "Enterprise Edition scratch org" --name "My Company" --target-dev-hub DevHub --set-default ``` (GitHub Feature Request [#2016](https://github.com/forcedotcom/cli/issues/2016), plugin-org PR [#641](https://github.com/salesforcecli/plugin-org/pull/641)) * NEW: Test Lightning web components with these `sfdx` commands that we added to `sf`: * `force lightning lwc test create` : Create a Lightning web component test file. * `force lightning lwc test run` : Invoke Lightning Web Components Jest unit tests. * `force lightning lwc test setup` : Install Jest unit testing tools for Lightning Web Components. The commands are in the JIT [plugin-lwc-test](https://github.com/salesforcecli/plugin-lwc-test) plugin. Rather than bundle it in the core Salesforce CLI, we automatically install the plugin the first time you run one of its commands, such as `force lightning lwc test create`. NOTE: If you use these commands, you must use version 16 of Node.js at this time due to an indirect dependency on `sa11y` which doesn't yet support version 18, the current LTS. See [this feature request](https://github.com/salesforce/sa11y/issues/376) for `sa11y` to support Node.js 18. See more information about Node.js versions [here](https://github.com/forcedotcom/cli/issues/1985). * FIX: If the `project deploy start` command fails, source-tracking information is updated correctly. (GitHub issue [#2057](https://github.com/forcedotcom/cli/issues/2057), source-tracking PR [#368](https://github.com/forcedotcom/source-tracking/pull/368)) * FIX: The `cmdt generate records` command correctly generates custom metadata type records and no longer returns the error `ModuleLoadError: [MODULE_NOT_FOUND]`. (GitHub issue [#2058](https://github.com/forcedotcom/cli/issues/2058), plugin-custom-metadata PR [#445](https://github.com/salesforcecli/plugin-custom-metadata/pull/445)) * FIX: Retrieving a reactivated PicklistValue metadata type no longer returns an erroneous error message. (GitHub issue [#960](https://github.com/forcedotcom/cli/issues/960), source-tracking PR [#960](https://github.com/forcedotcom/cli/issues/960)) ## 1.74.7 (April 19, 2023) * FIX: We've recently done a lot of work in the [source-deploy-retrieve](https://github.com/forcedotcom/source-deploy-retrieve) (SDR) library to address various issues that result in the error `Cannot read properties of undefined (reading 'something')`. These issues are often caused by metadata files being in an unexpected location or format. In addition to addressing these issues, we also now provide more useful errors with details about the name, type, and location of the file in your project that is causing the error. Our goal is to make it easier for you to find and fix the error if it's on your side, or quickly determine if it's actually a bug with Salesforce CLI. * FIX: The `sf org delete scratch` command now correctly deletes expired scratch orgs. (GitHub issue [#2045](https://github.com/forcedotcom/cli/issues/2045), plugin-org PR [#640](https://github.com/salesforcecli/plugin-org/pull/640)) * FIX: The `sf apex run test` command now correctly runs Apex tests asynchronously by default. (GitHub issue [#2035](https://github.com/forcedotcom/cli/issues/2035), plugin-apex PR [#91](https://github.com/salesforcecli/plugin-apex/pull/91)) ## 1.73.0 (April 12, 2023) * CHANGE: Instead of bundling [plugin-env](https://github.com/salesforcecli/plugin-env) in the core Salesforce CLI, we now automatically install it the first time you run one of its commands. As we announced on [March 1, 2023](./README.md#1670-march-1-2023), the commands in `plugin-env` (`env list|display|open`) work only with compute environments (Salesforce Functions). Because not all our customers use these commands regularly, we decided to make the plugin a just-in-time one. NOTE: This change applies only to _new_ Salesforce CLI installations. If the plugin is already installed in your Salesforce CLI, there's no change. * FIX: Running the `force source convert` command on Windows on a directory with Digital Experiences in it no longer produces a `package.xml` file with invalid entries. (GitHub issue [#2014](https://github.com/forcedotcom/cli/issues/2014), SDR PR [#911](https://github.com/forcedotcom/source-deploy-retrieve/pull/911)) ## 1.72.0 (April 5, 2023) * NEW: As part of [improving the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands so they work like the `sf` commands, we've reconciled the deploy and retrieve commands in [plugin-deploy-retrieve](https://github.com/salesforcecli/plugin-deploy-retrieve) and [plugin-source](https://github.com/salesforcecli/plugin-source). As a result, some existing `sf` command names have changed, and some `sfdx` commands now work in `sf`. Here's a summary. These commands are new: * `project convert mdapi` : Convert metadata retrieved via Metadata API into the source format used in Salesforce DX projects. * `project convert source` : Convert source-formatted files into metadata that you can deploy using Metadata API. * `project delete source` : Delete source from your project and from a non-source-tracked org. * `project delete tracking` : Delete all local source tracking information. * `project list ignored` : Check your local project package directories for forceignored files. * `project generate manifest` : Create a project manifest that lists the metadata components you want to deploy or retrieve. * `project reset tracking` : Reset local and remote source tracking. We renamed the following existing `sf` commands, but aliased the old names so you can still use them. We recommend you start using the new names soon. We also added a few flags to some commands. And all previously beta commands are now generally available. |Old Command Name|New Command Name|New Flags| |--------|--------|---| |`deploy metadata` | `project deploy start`|
  • `--coverage-formatters`
  • `--junit`
  • `--post-destructive-changes`
  • `--pre-destructive-changes`
  • `--purge-on-delete`
  • `--results-dir`
| |`deploy metadata cancel` | `project deploy cancel`|No new flags.| |`deploy metadata preview` | `project deploy preview`|No new flags.| |`deploy metadata quick` | `project deploy quick`|No new flags.| |`deploy metadata report` | `project deploy report`|
  • `--api-version`
  • `--coverage-formatters`
  • `--junit`
  • `--results-dir`
| |`deploy metadata resume` | `project deploy resume`|
  • `--coverage-formatters`
  • `--junit`
  • `--results-dir`
| |`deploy metadata validate` | `project deploy validate`|No new flags.| |`retrieve metadata` | `project retrieve start`|No new flags.| |`retrieve metadata preview` | `project retrieve preview`|No new flags.| Finally, we deprecated the interactive `sf deploy` command; use `project deploy start` or `deploy function` instead. As always, run the new and existing commands with the `--help` flag to get detailed information, or `-h` for a quick look. ## 1.71.0 (March 29, 2023) * CHANGE: We changed the long name of the flag to specify a Dev Hub org from `--target-hub-org` to `--target-dev-hub` for these packaging commands: * `package convert` * `package create` * `package delete` * `package list` * `package update` * `package version create` * `package version create list` * `package version create report` * `package version delete` * `package version displayancestry` * `package version list` * `package version promote` * `package version report` * `package version update We aliased the old long name to the new one, so nothing will break. But we highly recommend you update your scripts to use the new flag name. The short flag name (`-v`) didn't change. We made this change so the flag name matches the other `sf` commands. * FIX: Executing the `apex get log` command with the `--log-id` flag now correctly fetches the log with the specified ID. (GitHub issue [#2006](https://github.com/forcedotcom/cli/issues/2006), plugin-apex PR [#79](https://github.com/salesforcecli/plugin-apex/pull/79)) * FIX: The `--url-path-prefix` flag of the `community create` command is no longer required, which is the correct behavior. (GitHub issue [#2005](https://github.com/forcedotcom/cli/issues/2005), plugin-community PR [#303](https://github.com/salesforcecli/plugin-community/pull/303)) * FIX: Let's say you log into a Dev Hub org, and then log into a scratch org that's associated with it, but you created this scratch org from a different computer. Running `org list` on the first computer now correctly lists the scratch org and its expiration date in the appropriate section. (GitHub issue [#1941](https://github.com/forcedotcom/cli/issues/1941), sfdx-core PR [#775](https://github.com/forcedotcom/sfdx-core/pull/775)) * FIX: The `sf deploy|retrieve metadata` commands now support the ExtlClntAppGlobalOauthSettings metadata type. ## 1.70.0 (March 22, 2023) * NEW: As part of [improving the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands so they work like the `sf` commands, we've added these two new commands to `sf`: * `sf org list metadata` : List the metadata components and properties of a specified type. * `sf org list metadata-types` : Display details about the metadata types that are enabled for your org. We also added the `--source-file` flag to `sf open org` command so you can open a Lightning page in Lightning App Builder in your org. * CHANGE: Instead of bundling the [Salesforce Functions plugin](https://github.com/salesforcecli/plugin-functions) in the core Salesforce CLI, we now automatically install it the first time you run one of its commands. We made this change because not all of you use the Salesforce Functions commands regularly. (This change applies only to new Salesforce CLI installations. If the plugin is already installed in your Salesforce CLI, there's no change.) * FIX: We fixed the examples for the `sf apex run` command so they use the correct flag: `--file` instead of the incorrect `--apex-code-file`. (GitHub issue [#1999](https://github.com/forcedotcom/cli/issues/1999), plugin-apex PR [#71](https://github.com/salesforcecli/plugin-apex/pull/71)) ## 1.69.0 (March 15, 2023) FIX: We fixed some under-the-hood bugs. ## 1.68.2 (March 8, 2023) * NEW: We've made it easier for you to develop secure code by adding [Salesforce Code Analyzer](https://forcedotcom.github.io/sfdx-scanner/) as a "just-in-time" plugin. Simply type one of the commands, such as `sf scanner run`, and if the plugin isn't already installed, Salesforce CLI automatically installs the latest version. Then use the `sf scanner` commands to detect quality issues and security vulnerabilities in your code. As always, run a command with `--help` to see more information. And be sure to check the [prerequisites page](https://forcedotcom.github.io/sfdx-scanner/en/v3.x/getting-started/prerequisites/). * NEW: Generate your own custom plugins, commands, flags, and more with the commands in the just-in-time [plugin-dev](https://github.com/salesforcecli/plugin-dev). If you haven't already installed this plugin, simply type one of its commands and Salesforce CLI automatically installs it for you. For example, run this command to interactively generate the initial files and directory hierarchy for a new custom plugin; the command prompts you for the required information: ```bash sf dev generate plugin ``` See [Get Started and Create Your Own Plugin](https://github.com/salesforcecli/cli/wiki/Get-Started-And-Create-Your-First-Plug-In) for simple examples of using the new commands. See [Generate Stuff](https://github.com/salesforcecli/cli/wiki/Code-Your-Plugin#generate-stu) for the full list. * NEW: As part of [improving the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands so they work like the `sf` commands, we reconciled all `config` and `alias` commands in both executables into a single plugin: [plugin-settings](https://github.com/salesforcecli/plugin-settings). The commands work the same as before. Actually, some of the `config` commands work _better_ than before because you can now enter a slightly-misspelled configuration variable and the command prompts you with the correct name. Super handy if you forget the exact name of a config var. For example: ```bash $ sf config set version=57.0 ? Did you mean org-api-version? Yes Set Config =============================== | Name Value Success | ─────────────── ───── ─────── | org-api-version 57.0 true ``` **Important**: As announced [here](https://github.com/forcedotcom/cli/issues/1970), we introduced a breaking change in what the `sf config set --json` and `sf config unset --json` commands display; specifically they now produce slightly different JSON output. For example, this command: ```bash sf config set org-instance-url=https://test.salesforce.com --json ``` Now produces this output: ```json { "status": 0, "result": { "successes": [ { "name": "org-instance-url", "value": "https://test.salesforce.com", "success": true } ], "failures": [] }, "warnings": [] } ``` Previously it produced this output: ```json { "status": 0, "result": [ { "name": "org-instance-url", "value": "https://test.salesforce.com", "success": true } ], "warnings": [] } ``` The JSON output of `sf config unset --json` changed similarly. There is no change in the other `config` and `alias` commands. * CHANGE: When running any `sf retrieve metadata` command with the `--json` flag, we no longer include the `zipfile` property in the `result`. (plugin-deploy-retrieve PR [#514](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/514)) ## 1.67.0 (March 1, 2023) * NEW: We continue to improve the usability of existing `sfdx` commands so they work like the `sf` commands. We're doing this work plugin by plugin. As a result of this work, when a Salesforce CLI release includes an updated plugin, you can execute the plugin's commands in both `sfdx` AND `sf`. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. This week we've reconciled the various authentication and login commands between `sfdx` and `sf`. We've added the updated `sfdx` [plugin-auth](https://github.com/salesforcecli/plugin-auth) to `sf`, and made changes to the existing `sf` [plugin-env](https://github.com/salesforcecli/plugin-env) and [plugin-login](https://github.com/salesforcecli/plugin-login). Here's a summary of the changes. Use these commands to log in and authorize an org: * `sf org login jwt` : Log in to a Salesforce org using a JSON web token (JWT). * `sf org login web` : Log in to a Salesforce org using the web server flow. * `sf org logout` : Log out of a Salesforce org. * `sf org list auth` : List authorization information about the orgs you created or logged into. * `sf org login access-token` : Authorize an org using an existing Salesforce access token. * `sf org login device` : Authorize an org using a device code * `sf org login sfdx-url` : Authorize an org using a Salesforce DX authorization URL stored in a file. Here's how the existing `sf` commands have changed: |Existing Command|Changes| |-----|-----| |`sf login org jwt`|Original command has been removed, use `sf org login jwt` instead.| |`sf login org`|Original command has been removed, use `sf org login web` instead| |`sf logout org`|Original command has been removed, use `sf org logout` instead| |`sf logout`|Command is deprecated and no longer works on orgs. Use `sf org logout` instead| |`sf login`|Command is deprecated and no longer works on orgs. Use `sf org login web` instead| |`sf env display`|Works only with compute environments, not with orgs. Use `sf org display` instead.| |`sf env list`|Works only with compute environments, not with orgs. Use `sf org list auth` or `sf org list` instead.| |`sf env open`|Works only with compute environments, not with orgs. Use `sf org open` instead.| * NEW: Use Bulk API 2.0 to upsert and delete data to and from your org with these new commands: * `sf data delete bulk` : Bulk delete records from an org using a CSV file. Uses Bulk API 2.0. * `sf data delete resume` : Resume a bulk delete job that you previously started. Uses Bulk API 2.0. * `sf data upsert bulk` : Bulk upsert records to an org from a CSV file. Uses Bulk API 2.0. * `sf data upsert resume` : Resume a bulk upsert job that you previously started. Uses Bulk API 2.0. For example, bulk upsert records from a CSV file to the Contact object in your default org with this command: ```bash sf data upsert bulk --sobject Contact --file files/contacts.csv --external-id Id ``` The preceding command returns control to you immediately and runs the bulk upsert asynchronously. Resume the job to see the results with this command: ```bash $ sf data upsert resume --use-most-recent ``` We recommend that you start using these new Bulk API 2.0 commands rather than the existing `sf force data bulk` commands, which are based on Bulk API 1.0. However, one reason to keep using the existing `sf force data bulk upsert` command is if you want to run the upsert serially with the `--serial` flag. The new Bulk API 2.0 commands don't support serial execution. In this case, or if you simply want to continue using Bulk API 1.0, use these commands: * `sf force data bulk delete` * `sf force data bulk upsert` * `sf force data bulk status` Run the commands with `--help` to see examples. Finally, the `sf data resume` command is deprecated. Use `sf data delete resume` or `sf data upsert resume` instead. * NEW: When you type a command fragment and `sf` displays a list of possible commands for you to choose from, we now also display the command summary. The summaries make it easier for you to pick the command you want. * CHANGE: Due to low usage and high complexity, we removed the Salesforce Functions `sf run function start container` command; use `sf run function start` instead. * FIX: You can now specify `packageAliases` that contain spaces in the `sfdx-project.json` file and execute `package` commands that use the alias without getting an error. (GitHub issue [#1936](https://github.com/forcedotcom/cli/issues/1936), oclif PR [#614](https://github.com/oclif/core/pull/614)) * FIX: For backwards compatibility, we added the `-v|--targetdevhubusername` flag back to the `force org delete` and `org delete scratch` commands, even though the flag doesn't do anything and is deprecated. (GitHub issue [#1925](https://github.com/forcedotcom/cli/issues/1925), plugin-org PR [#581](https://github.com/salesforcecli/plugin-org/pull/581)) * FIX: When the `sf org create scratch` command deploys the org settings, it waits for the amount of time left from the specified `--wait` value. Previously it waited for a maximum of 10 minutes for this step, regardless of the value of `--wait`. (GitHub issue [#1817](https://github.com/forcedotcom/cli/issues/1817), sfdx-core PR [#771](https://github.com/forcedotcom/sfdx-core/pull/771)) * FIX: If you run into authentication errors when running `sf org list shape`, such as an expired refresh token, the displayed table now shows information for orgs the command can connect to, and an appropriate warning for orgs it can't connect to. (GitHub issue [#1882](https://github.com/forcedotcom/cli/issues/1882), plugin-signups PR [#216](https://github.com/salesforcecli/plugin-signups/pull/216)) ## 1.66.2 (Feb 22, 2023) * NEW: We now install some plugins just when you need them, rather than include them automatically in a Salesforce CLI release. Let's use the [updated]((https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli)) [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) as an example. The plugin isn't included in `sf` by default, although `sf` _knows_ about it. When you run one of the plugin's commands for the first time, such as `sf package version create`, Salesforce CLI installs the latest released version of the plugin and then runs the command. The installation happens automatically, although we display a little message so you know what's going on. From then on, run any of the commands contained in the plugin as usual. And when you next run `sfdx update`, if the just-in-time plugin has released a new version, then it's also updated. Just a little just-in-time magic! * NEW: We continue to improve the usability of existing `sfdx` commands so they work like the `sf` commands. We're doing this work plugin by plugin. As a result of this work, when a Salesforce CLI release includes an updated plugin, you can execute the plugin's commands in both `sfdx` AND `sf`. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. This week's release includes the updated [plugin-apex](https://github.com/salesforcecli/plugin-apex) and [plugin-templates](https://github.com/salesforcecli/plugin-templates). Consequently, you can now run these existing `sfdx` commands in `sf`: * `sf analytics generate template` : Create a simple Analytics template. * `sf apex run` : Execute anonymous Apex code entered on the command line or from a local file. * `sf apex generate class` : Create an Apex class. * `sf apex generate trigger` : Create an Apex trigger. * `sf apex get log` : Fetch the specified log or given number of most recent logs from the org. * `sf apex list log` : Display a list of IDs and general information about debug logs. * `sf apex tail log` : Activate debug logging and display logs in the terminal. * `sf apex get test` : Display test results for a specific asynchronous test run. * `sf apex run test` : Invoke Apex tests in an org. * `sf lightning generate app` : Create a Lightning App. * `sf lightning generate component` : Create a bundle for an Aura component or a Lightning web component. * `sf lightning generate event` : Create a Lightning Event. * `sf lightning generate interface` : Create a Lightning Interface. * `sf lightning generate test` : Create a Lightning test. * `sf static-resource generate` : Create a static resource. * `sf visualforce generate component` : Create a Visualforce Component. * `sf visualforce generate page` : Create a Visualforce Page. We also changed the official name of the existing `sf generate project` command to `sf project generate`. In addition to the two new _included_ plugins, we also added [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) as a just-in-time plugin. We decided to make it a just-in-time plugin because not all of you use the packaging commands regularly. See the previous release note about how this type of plugin works. After Salesforce CLI installs the plugin, you can run these existing `sfdx` commands in `sf`: * `sf package1 version create` : Create a first-generation package version in the release org. * `sf package1 version create get` : Retrieve the status of a package version creation request. * `sf package1 version display` : Display details about a first-generation package version. * `sf package1 version list` : List package versions for the specified first-generation package or for the org. * `sf package create`: Create a package. * `sf package delete` : Delete a package. * `sf package install`: Install a version of a package in the target org. * `sf package install report` : Retrieve the status of a package installation request. * `sf package installed list` : List the org’s installed packages. * `sf package list` : List all packages in the Dev Hub org. * `sf package uninstall` : Uninstall a second-generation package from the target org. * `sf package uninstall report` : Retrieve the status of a package uninstall request. * `sf package update` : Update package details. * `sf package version create` : Create a package version in the Dev Hub org. * `sf package version create list` : List package version creation requests. * `sf package version create report` : Retrieve details about a package version creation request. * `sf package version delete` : Delete a package version. * `sf package version displayancestry` : Display the ancestry tree for a 2GP managed package version. * `sf package version list` : List all package versions in the Dev Hub org. * `sf package version promote` : Promote a package version to released. * `sf package version report` : Retrieve details about a package version in the Dev Hub org. * `sf package version update` : Update a package version. As always, run the commands with `--help` to see the list of flags, examples, and usage information. We'll be releasing other updated plugins over the next weeks. Enjoy! * NEW: The `sf org display` output now includes the API version of the org at the time you authorized it with the `sf login org` command. We cache the value locally, so if Salesforce updates your org to a new release, the API version will be incorrect. Re-login to your org to refresh the API version information in the `sf org display` output. (GitHub issue [#314](https://github.com/forcedotcom/cli/issues/314), plugin-org PR [#580](https://github.com/salesforcecli/plugin-org/pull/580)) * NEW: Configure autocomplete on Zsh for commands that use spaces as separators by running this command: ```bash sf autocomplete ``` Follow the displayed instructions to set up autocomplete in your environment. Then use the tab key to autocomplete commands. For example, if you type `sf data ` then press TAB, you'll get a list of data commands to chose from. You can also autocomplete flags: * Type `-` to see suggestions that show both the long and short flag names. For example, if you type `sf data query -` then press TAB, zsh displays all the flags for this command, including both short and long names. If you type `sf data query --`, then only the long names are shown. * For flags that define a set of valid values, type `--` to see the list. For example, if you type `sf data query --result-format` then press TAB, zsh suggests the valid options for this flag, which are `human`, `json`, or `csv`. * Flags that can be specified multiple times are still suggested, even if you've already used it. If you currently use autocomplete for colon-separated commands, you must regenerate the autocomplete cache to get this new behavior; nothing in your environment changes otherwise: ```bash sf autocomplete --refresh-cache ``` If you regenerate the cache, but then want to go back to autocompleting commands that use `:` as a separator, first set this environment variable: ```bash OCLIF_AUTOCOMPLETE_TOPIC_SEPARATOR=colon ``` Then regenerate the autocomplete cache (`sf autocomplete --refresh-cache`). * CHANGE: Remember when we added [`plugin-custom-metadata`](#cmdt-community), [`plugin-signups`](#signups), and [`plugin-community`](#cmdt-community) to `sf`? We're changing them to just-in-time plugins, because, like packaging, not all of you use these commands regularly. ## 1.65.0 (Feb 15, 2023) * CHANGE: We upgraded the version of Node.js contained in the [Salesforce CLI installers and TAR files](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm) to [v18.14.0](https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V18.md#2023-02-02-version-18140-hydrogen-lts-bethgriggs-prepared-by-juanarbol). * FIX: The `sf data query` command no longer suppresess or nullifies the value of `0` (in human-readable output) when it's returned by a SOQL query. (GitHub issue [#1892](https://github.com/forcedotcom/cli/issues/1892), plugin-data PR [#470](https://github.com/salesforcecli/plugin-data/pull/470)) Many thanks to [Leo Stewart](https://github.com/leostewart) for reporting the issue, and then providing the fix. We're stoked with your contribution, and we look forward to more from you and community! * FIX: The `sf deploy|retrieve metadata` commands now support the ExperiencePropertyTypeBundle metadata type. ## 1.64.0 (Feb 8, 2023) * CHANGE: As part of [this project](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli), we changed the official name of these existing `sf` commands: | Old command name | New command name| |---|---| |`sf env create sandbox`|`sf org create sandbox`| |`sf env create scratch`|`sf org create scratch`| |`sf env delete sandbox`|`sf org delete sandbox`| |`sf env delete scratch`|`sf org delete scratch`| |`sf env resume sandbox`|`sf org resume sandbox`| |`sf env resume scratch`|`sf org resume scratch`| We also brought over these org-specific `sfdx` commands: * `sf org display` : Display information about an org. * `sf org list` : List all orgs you’ve created or authenticated to. * `sf org open` : Open your default scratch org, or another specified org, in a browser. We recommend you use their `env` equivalents (`sf env display|list|open`) for Salesforce Functions. * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * AccountingFieldMapping * AccountingModelConfig * ActionLauncherItemDef * ActionableListDefinition * ExplainabilityMsgTemplate * IntegrationProviderDef * LocationUse * PersonAccountOwnerPowerUser * PipelineInspMetricConfig * ProductSpecificationTypeDefinition ## 1.63.2 (Feb 1, 2023) These changes are in the Salesforce CLI release candidate. We plan to include these changes in next week's official release. This list isn't final and is subject to change. * NEW: We continue to improve the usability of existing `sfdx` commands so they work like the `sf` commands. We're doing this work plugin by plugin. As a result of this work, when a Salesforce CLI release includes an updated plugin, you can execute the plugin's commands in both `sfdx` AND `sf`. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. This week's release includes the updated [plugin-user](https://github.com/salesforcecli/plugin-user). Consequently, you can now run these existing `sfdx` commands in `sf`: * `sf org assign permset` : Assign a permission set to one or more users of a scratch org. * `sf org assign permsetlicense` : Assign a permission set license to one or more users of a scratch org. * `sf org create user` : Create a user for a scratch org. * `sf org display user` : Display information about a Salesforce user. * `sf org generate password` : Generate a random password for scratch org users. * `sf org list users` : List all locally-authenticated users of an org. As always, run the commands with `--help` to see the list of flags, examples, and usage information. We'll be releasing other updated plugins over the next weeks. Enjoy! * CHANGE: We changed the official names of these `sf` commands that we recently added: | Old command name | New command name| |---|---| |`sf generate cmdt object`|`sf cmdt generate object`| |`sf generate cmdt field `|`sf cmdt generate field `| |`sf generate cmdt fromorg`|`sf cmdt generate fromorg`| |`sf generate cmdt record`|`sf cmdt generate record`| |`sf generate cmdt records`|`sf cmdt generate records`| |`sf generate metadata field` |`sf schema generate field`| |`sf generate metadata platformevent` |`sf schema generate platformevent`| |`sf generate metadata sobject` |`sf schema generate sobject`| |`sf generate metadata tab` |`sf schema generate tab`| * FIX: When running `sf env delete scratch|sandbox` to delete a scratch or sandbox org, all local source tracking files associated with the deleted org are cleaned up correctly. (GitHub issue [#1879](https://github.com/forcedotcom/cli/issues/1879), sfdx-core PR [#754](https://github.com/forcedotcom/sfdx-core/pull/754)) * FIX: The `cmdt generate record` command is now working correctly and no longer returns `Error: Unexpected arguments`. (GitHub issue [#1893](https://github.com/forcedotcom/cli/issues/1893), plugin-custom-metadata PR [#380](https://github.com/salesforcecli/plugin-custom-metadata/pull/380)) ## 1.62.2 (Jan 25, 2023) * NEW: We continue to improve the usability of existing `sfdx` commands so they work like the `sf` commands. We're doing this work plugin by plugin. As a result of this work, when a Salesforce CLI release includes an updated plugin, you can execute the plugin's commands in both `sfdx` AND `sf`. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. This week's release includes updated [plugin-signups](https://github.com/salesforcecli/plugin-signups). Consequently, you can now run these existing `sfdx` commands in `sf`: * `sf org create shape` : Create a scratch org configuration (shape) based on the specified source org. * `sf org delete shape` : Delete all org shapes for a target org. * `sf org list shape` : List all org shapes you’ve created. * `sf org create snapshot` : Create a snapshot of a scratch org. (Pilot) * `sf org delete snapshot` : Delete a scratch org snapshot. (Pilot) * `sf org get snapshot` : Get details about a scratch org snapshot. (Pilot) * `sf org list snapshot` : List scratch org snapshots. (Pilot) As always, run the commands with `--help` to see the list of flags, examples, and usage information. We'll be releasing other updated plugins over the next weeks. Enjoy! * NEW: You can now automatically replace snippets of your metadata source files with specific values right before you deploy the files to an org with the `sf deploy metadata` command. This string replacement is "ephemeral" because the changes aren't written to your project; they apply only to the deployed files. Use this new feature to, for example, replace the endpoint in a NamedCredential, depending on whether you're deploying to a production or scratch org. Or specify a password in an ExternalDataSource that you don't want to store in your repo. The use cases are endless! To configure string replacement, add a `replacements` property to your `sfdx-project.json` file and use key-value pairs to describe how the string replacement works. See [Replace Strings in Code Before Deploying](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_string_replace.htm) for details and examples. This topic uses the `force:source:deploy|push` sfdx commands in the examples, but they apply equally to `sf deploy metadata`. Note these `sf`-specific considerations: * By default, if you specify the `--json` flag for `sf metadata deploy`, the JSON output includes a `replacements` property that lists the affected files and the string that was replaced. Specify the `--concise` flag to omit this information. * To view string replacement information in the `sf metadata deploy` human-readable output, specify `--verbose`. ## 1.61.1 (Jan 18, 2023) * NEW: We continue to improve the usability of existing `sfdx` commands so they work like the `sf` commands. We're doing this work plugin by plugin. As a result of this work, when a Salesforce CLI release includes an updated plugin, you can execute the plugin's commands in both `sfdx` AND `sf`. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. This week's release includes updated [plugin-data](https://github.com/salesforcecli/plugin-data), [plugin-community](https://github.com/salesforcecli/plugin-community), and [plugin-custom-metadata](https://github.com/salesforcecli/plugin-custom-metadata). Consequently, you can now run these existing `sfdx` commands in `sf`: * `sf community create` : Create an Experience Cloud site using a template. * `sf community list template` : Retrieve the list of templates available in your org. * `sf community publish` : Publish an Experience Builder site to make it live. * `sf data create record` : Create and insert a record into a Salesforce or Tooling API object. * `sf data delete bulk` : Bulk delete records from an org using a CSV file. * `sf data delete record` : Deletes a single record from a Salesforce or Tooling API object. * `sf data export tree` : Export data from an org into one or more JSON files. * `sf data get record` : Retrieve and display a single record of a Salesforce or Tooling API object. * `sf data import tree` : Import data from one or more JSON files into an org. * `sf data query` : Execute a SOQL query. * `sf data query resume` : View the status of a bulk query. * `sf data resume` : View the status of a bulk data load job or batch. * `sf data update record` : Updates a single record of a Salesforce or Tooling API object. * `sf data upsert bulk` : Bulk upsert records to an org from a CSV file. * `sf generate cmdt object` : Generate a new custom metadata type in the current project. * `sf generate cmdt field ` : Generate a field for a custom metadata type based on the provided field type. * `sf generate cmdt fromorg` : Generate a custom metadata type and all its records from a Salesforce object. * `sf generate cmdt record` : Generate a new record for a given custom metadata type in the current project. * `sf generate cmdt records` : Generate new custom metadata type records from a CSV file. As always, run the commands with `--help` to see the list of flags, examples, and usage information. We'll be releasing other updated plugins over the next weeks. Enjoy! ## 1.60.0 (Jan 11, 2023) ANNOUNCEMENT: Happy new year, Salesforce CLI community! Be sure to read our latest [blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) that describes some of the big improvements that are coming in Salesforce CLI this year. And now back to our regular schedule. * NEW: As described in [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli), we're updating many of the existing `sfdx` commands to use the improvements we made in `sf`. We're doing this work plugin by plugin. When a Salesforce CLI release includes an updated plugin, you can execute the plugin's commands in both `sfdx` AND `sf`. Let's see how this works. This week's release includes updated [plugin-limits](https://github.com/salesforcecli/plugin-limits) and [plugin-schema](https://github.com/salesforcecli/plugin-schema). As a result, you can now run these existing `sfdx` commands in `sf`: * `sf limits api display`: Display information about limits in your org. * `sf limits recordcounts display`: Display record counts for the specified standard or custom objects. * `sf sobject describe`: Display the metadata for a standard or custom object or a Tooling API object. * `sf sobject list`: List all Salesforce objects of a specified category. As always, run the commands with `--help` to see the list of flags, examples, and usage information. We'll be releasing other updated plugins over the next weeks. Enjoy! * CHANGE: Salesforce CLI has always automatically run a partial command if it finds only one option. For example, if you run `sf open`, the CLI runs `sf env open` automatically because it's the only command that contains the fragment `open`. But now we warn you about it, just so you know exactly what command you just ran. [cli PR [#475](https://github.com/salesforcecli/cli/pull/475)) ## 1.59.0 (Dec 21, 2022) * NEW: Get debugging information about any command execution with the new `--dev-debug` flag. Each line in the debug output starts with the name of a function or plugin, such as `sf:core`. Use these values to filter the debug output with the `--debug-filter` flag. For example: `sf env list --dev-debug --debug-filter sf:core` (salesforce/cli PR [#452](https://github.com/salesforcecli/cli/pull/452)) * FIX: The `sf deploy|retrieve metadata` commands now support these metdata types used by Net Zero Cloud: * FuelType * FuelTypeSustnUom * SustainabilityUom * SustnUomConversion ## 1.58.0 (Dec 14, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.57.0 (Dec 7, 2022) * FIX: Any configured `postorgcreate` hooks in custom plugins are now firing correctly after you run `sf env create scratch|sandbox`. ## 1.56.0 (Nov 30, 2022) * NEW: Do you write plugins for Salesforce CLI (`sf` executable)? If so, check out the new `sf dev audit messages` command in [plugin-dev](https://github.com/salesforcecli/plugin-dev). It audits your plugin's messages directory, looking for unused messages and missing messages referenced by your source code. If you don't specify any flags, you must run it from your plugin's top-level directory. First make sure you've installed the plugin: ```bash sf plugins install @salesforce/plugin-dev ``` Then change to your plugin directory and get an audit of your messages: ```bash sf dev audit messages ``` Or run the command from anywhere and use the `--project-dir` flag to specify your plugin directory: ```bash sf dev audit messages --project-dir /User/romeo/my-plugin (macOS/Linux) sf dev audit messages --project-dir c:\custom-plugins\my-plugin (Windows) ``` Maybe you haven't yet written your own `sf` plugin, but you're curious? We've made it super easy. Check out the [sf Plugin Developer Guide](https://github.com/salesforcecli/cli/wiki/Quick-Introduction-to-Developing-sf-Plugins) for all the deets, or just [plunge right in](https://github.com/salesforcecli/cli/wiki/Get-Started-And-Create-Your-First-Plug-In). Happy coding! * FIX: The `sf env resume scratch` command displays the correct message. (GitHub issue [#1701](https://github.com/forcedotcom/cli/issues/1701). sfdx-core PR [#706](https://github.com/forcedotcom/sfdx-core/pull/706)) ## 1.55.0 (Nov 23, 2022) * FIX: The `sf deploy|retrieve metadata` commands now support the ExtlClntAppMobileConfigurablePolicies metadata type. ## 1.54.0 (Nov 16, 2022) * NEW: Determine which plugin a command is in with the new `which` command. For example: ```bash $ sf which "deploy metadata" === deploy metadata plugin: @salesforce/plugin-deploy-retrieve ``` * FIX: The `sf deploy|retrieve metadata` commands now support these metdata types: * ExtlClntAppOauthConfigurablePolicies (previously called ExtlClntAppOauthPlcyCnfg) * ExtlClntAppMobileSettings (previously called ExtlClntAppMobileSet) ## 1.53.0 (Nov 9, 2022) * NEW: Quickly gather Salesforce CLI configuration data and run diagnostic tests with the new `doctor` command. Use the command to easily generate informational files that you can attach to [GitHub issues](https://github.com/forcedotcom/cli/issues) or provide to Salesforce Customer Support. Run without parameters, the command first displays basic information, such as whether you're on the latest CLI version. It then writes your configuration and a detailed diagnosis to a JSON file in the current directory. Use the `--outputdir` flag to specify a different directory. For example: `sf doctor --outputdir diagnostic-files` Use the `--command` flag to run a specific command in debug mode; the doctor writes both stdout and stderr to separate `*.log` files. Encapsulate the command in double quotes. For example: `sf doctor --command "env list --all"` To run diagnostic tests on a specific plugin rather than the CLI itself, use the `--plugin` flag. If the plugin isn't listening to the doctor, then you get a warning and no data. `sf doctor --plugin @salesforce/plugin-deploy-retrieve` We've made it really easy to create a GitHub issue: specify the `--createissue` flag, enter a title at the prompt, and a browser window automatically opens with a partially-filled GitHub issue. Enter the remaining information about your specific issue, click **Submit new issue**, and you're done. Easy peasy! The CLI doctor is in and ready to diagnose all your problems! ## 1.52.0 (Nov 2, 2022) * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * BotBlock * ClauseCatgConfiguration * DisclosureType * DisclosureDefinition * DisclosureDefinitionVersion * ExtlClntAppOauthPlcyCnfg * ExtlClntAppOauthSettings * ExtlClntAppMobileSet * OmniSupervisorConfig ## 1.51.0 (Oct 26, 2022) * NEW: Create aliases to simplify how you use the CLI with these new beta commands: * `sf alias set` * `sf alias unset` * `sf alias list` For example, scratch org usernames are long and unwieldy, such as `test-sadbiytjsupn@example.com`. Creating an alias for the username, such as `my-scratch-org` makes it easy to refer to it. Check the `--help` of a CLI command to determine where you can use an alias. Here's how to set an alias to a scratch org username: `sf alias set my-scratch-org=test-sadbiytjsupn@example.com` Refer to the alias this way: `sf deploy metadata --target-org my-scratch-org --metadata ApexClass` Enjoy! ## 1.50.0 (Oct 19, 2022) * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * CallCtrAgentFavTrfrDest * ExternalCredential * MarketSegmentDefinition * MfgProgramTemplate * StreamingAppDataConnector ## 1.49.0 (Oct 12, 2022) * FIX: The `sf deploy metadata` command correctly deploys any CustomFieldTranslation metadata types that have local changes. (PRs: source-deploy-retrieve [#726](https://github.com/forcedotcom/source-deploy-retrieve/pull/726) and [#728](https://github.com/forcedotcom/source-deploy-retrieve/pull/728), plugin-source [#597](https://github.com/salesforcecli/plugin-source/pull/597), source-tracking [#243](https://github.com/forcedotcom/source-tracking/pull/243)) * FIX: The `sf deploy metadata` command correctly handles the new enhanced domains in Winter '23 preview sandboxes. [GitHub issue [#1687](https://github.com/forcedotcom/cli/issues/1687). PRs: jsforce [#1272](https://github.com/jsforce/jsforce/pull/1272), sfdx-core [#667](https://github.com/forcedotcom/sfdx-core/pull/667)) * FIX: The `sf deploy|retrieve metadata` commands now support the RelationshipGraphDefinition metadata type. [PR: source-deploy-retrieve [#722](https://github.com/forcedotcom/source-deploy-retrieve/pull/722)) ## 1.48.0 (Oct 5, 2022) * FIX: When you install a plugin with the `sf plugin install` command, `sf` now verifies its signature. If the plugin is unsigned, `sf` prompts you to confirm that you really want to install it. This behavior mimics the existing behavior of `sfdx`. ## 1.47.0 (Sept 28, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.46.0 (Sept 21, 2022) * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * DigitalExperienceBundle * DigitalExperience * DigitalExperienceConfig * FIX: You can now correctly deploy empty metadata files; previously you'd get an UNKNOWN_EXCEPTION error. (GitHub issue [#1673](https://github.com/forcedotcom/cli/issues/1673), SDR PR [#705](https://github.com/forcedotcom/source-deploy-retrieve/pull/705)) ## 1.45.0 (Sept 14, 2022) * NEW: Retrieve components in metadata format with the new `--target-metadata-dir | -t` flag of the `sf retrieve metadata` command. _Metadata format_ refers to the file format used by the Metadata API. Previously, the `sf retrieve metadata` command retrieved files only in source format. With the new `--target-metadata-dir` flag, the components in metadata format are retrieved into a ZIP file called `unpackaged.zip` (by default) in the specified local directory. You must use this flag in combination with one of these flags so the command knows which components to retrieve: `--source-dir`, `--manifest`, `--metadata`, or `--package-name`. For example, this command retrieves all Apex classes from an org with alias `myorg` into a ZIP file called `unpackaged.zip` and puts it in the local directory called `md-output`: `sf retrieve metadata --metadata ApexClass --target-metadata-dir md-output --target-org myorg` Customize the command output with these other new flags: * `--single-package`: Indicates that the retrieved ZIP file has a single package directory. * `--unzip, -z`: Automatically extract the files from the downloaded ZIP file. * `--zip-file-name`: Name for the downloaded ZIP file. Default is `unpackaged.zip`. For example: `sf retrieve metadata --metadata ApexClass --target-metadata-dir md-output --unzip --target-org myorg` * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * ExternalClientApplication * ForecastingFilter * ForecastingFilterCondition * SchedulingObjective ## 1.44.0 (Sept 8, 2022) * FIX: The `sf deploy|retrieve metadata` commands now support the MarketingAppExtension metadata type. ## 1.43.0 (Sept 1, 2022) * NEW: Preview a metadata deployment or retrieval with the new `sf deploy|retrieve metadata preview` beta commands. They're like `sfdx force:source:status`, but smarter. The commands display a table of the metadata components that will be deployed or retrieved or deleted. The table also lists the conflicts between the source in your local project and the components in the org. Finally, the table lists components that won't be deployed or retrieved because they're included in your `.forceignore` file. Use the `--ignore-conflicts` to see what is deployed or retrieved when any conflicts are ignored. For example: `sf retrieve metadata preview --ignore-conflicts` The `sf deploy metadata preview` command also supports the flags to narrow what's deployed, such as `--metadata`, `--manifest`, or `--source-dir`. For example: ```bash sf deploy metadata preview --metadata ApexClass sf deploy metadata preview --source-dir force-app ``` * NEW: Interactively create local Salesforce metadata, such as custom objects and platform events, with these new beta commands in the new [plugin-sobject](https://github.com/salesforcecli/plugin-sobject) plug-in: ```bash sf generate metadata sobject sf generate metadata platformevent sf generate metadata field ``` Each command requires the `--label` flag, and then uses the value to provide intelligent suggestions for its prompts, such as its API name. This example shows how to interactively create a custom object: `sf generate metadata sobject --label "My Fab Object"` Want to automatically enable optional features on the new custom object rather than answer all the prompts? Try this: `sf generate metadata sobject --label "My Fab Object" --use-default-features` Now create a custom field on your shiny new object; the command prompts you for the object: `sf generate metadata field --label "My Field"` Remember to run `sf deploy metadata` to deploy the new local source files to your org. Then you can further customize the new components using Setup UI, then `sf retrieve metadata` the changes back to your local project. How fun is that? * NEW: Create a custom tab for a custom object with the new `sf generate metadata tab` beta command. You must provide the object's API name, [icon number](https://www.lightningdesignsystem.com/icons/#custom), and local directory to store the files. For example: `sf generate metadata tab --object MyFabObject__c --icon 54 --directory force-app/main/default/tabs` ## 1.42.0 (Aug 25, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.41.0 (Aug 18, 2022) * NEW: Search the `sf` commands for that special one you've been looking for all your life with the new interactive `sf search` command. * CHANGE: The `sf deploy|retrieve metadata` commands no longer support these metadata types associated with Connect Center: * ConnectedSystem * DataMapping * DataMappingObjectDefinition * DataMappingSchema * DataMappingFieldDefinition * FederationDataMappingUsage ## 1.40.0 (Aug 11, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.39.0 (Aug 4, 2022) * FIX: Following our standard conventions, these commands no longer have the `-j` short flag for producing JSON output, only the `--json` long flag: * `sf deploy functions` * `sf env create compute` * `sf env delete` * `sf env logdrain add` * `sf env logdrain remove` * `sf env var set` * `sf env var unset` * `sf logout functions` * `sf run function` ## 1.38.0 (July 28, 2022) * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * IdentityVerificationProcDef * ServiceAISetupDefinition * ServiceAISetupField ## 1.37.0 (July 21, 2022) * NEW: Get JSON output from these Salesforce Functions commands with the `--json` flag: * `sf deploy functions` * `sf env create compute` * `sf env delete` * `sf env logdrain add` * `sf env logdrain remove` * `sf env var set` * `sf env var unset` * `sf logout functions` * `sf run function` * NEW: Stream log output for a compute environment with the new beta `sf env log` command. For example: `sf env log --target-compute environment-alias` * FIX: Refreshing expired access tokens is working as expected. (GitHub issue [#1615](https://github.com/forcedotcom/cli/issues/1615), [sfdx-core PR #619](https://github.com/forcedotcom/sfdx-core/pull/619)) * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * AIUsecaseDefinition * DataPackageKitDefinition * DataPackageKitObject * DataSourceBundleDefinition * DataSrcDataModelFieldMap * DataStreamTemplate ## 1.36.0 (July 14, 2022) * FIX: The `sf env create scratch` command correctly labels a scratch org in its internal authentication files. (GitHub issue https://github.com/forcedotcom/cli/issues/1598) ## 1.35.0 (July 7, 2022) * NEW: These commands now support source tracking: * `sf deploy metadata` * `sf deploy metadata validate` * `sf retrieve metadata` The first time you run `sf deploy metadata` on a scratch or sandbox org that allows source tracking, the command deploys all local source files. But when you next run the command, it deploys only the files that changed locally. Narrow the list of deployed files with the `--source-dir`, `--metadata`, or `--manifest` flags. If you don’t specify these flags, then the command deploys all changes in the project, similar to how `force:source:push` in `sfdx` works. The `sf retrieve metadat`a command is the same as deploy, but in reverse. The first time you retrieve, everything is retrieved; the next time only changes in the org are retrieved. If you don’t specify `--source-dir`, `--metadat`a, or `--manifest`, then all changes in the org are retrieved, just like `force:source:pull` in `sfdx`. If a command detects a conflict in the files you’re about to deploy or retrieve, the command displays the conflicts. Use the `--ignore-conflicts` flag to force the deployment or retrieval of the changes. This flag is similar to the`--forceoverwrite` parameter of many of the `force:source` commands in `sfdx`. For example: `sf deploy metadata --source-dir force-app --ignore-conflicts` See [Getting Started with Salesforce CLI Unification](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_sf_intro.htm), which will soon be updated with additional details about source tracking in `sf` and how it’s slightly different from `sfdx`. * NEW: Opt out of source tracking when you create a scratch or sandbox org with the new `--no-track-source` flag of the `sf env create scratch|sandbox` commands. Source tracking is enabled by default for orgs that support it. But you sometimes want to disable source tracking, such as in a CI/CD environment to improve performance. This example creates a scratch org with source tracking disabled: `sf env create scratch --target-dev-hub=MyHub --definition-file config/project-scratch-def.json --no-track-source` * NEW: Get detailed information about the Salesforce CLI version you're using with the new `--verbose` flag of the `sf version` command. Output includes versions of the core and installed plug-ins, operating system information, and version of Node.js. * FIX: Authentication tokens are now consistently and correctly encrypted or decrypted. (GitHub issue #[1314](https://github.com/forcedotcom/cli/issues/1314)) ## 1.34.0 (June 30, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.33.0 (June 23, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.32.0 (June 16, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.31.0 (June 9, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.30.0 (June 2, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.29.0 (May 26, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.28.0 (May 19, 2022) * NEW: Deploy components in metadata format with these new flags for the `sf deploy metadata` and `sf deploy metadata validate` commands: * `--metadata-dir`: Either the root directory or the .zip file that contains the metadata formatted files you want to deploy. * `--single-package`: Indicates that `--metadata-dir` points to a directory structure for a single package. By default, the deploy command assumes the directory is structured for a set of packages. _Metadata format_ refers to the file format used by the Metadata API. Previously, the `sf deploy metadata` and `sf deploy metadata validate` commands deployed files only in source format. If you use `--metdata-dir` to deploy metadata formatted source files, you can't use the `--metadata`, `--source-dir`, or `--manifest` flags, which apply only to source formatted files. This example deploys the metadata formatted files in the `MyMdComponents.zip` file and specifies that the files are in a single package directory: ```sf deploy metadata --metadata-dir zips/MyMdComponents.zip --single-directory``` * FIX: The `sf deploy|retrieve metadata` commands now support these metadata types: * AssessmentQuestion * AssessmentQuestionSet ## 1.27.0 (May 12, 2022) * NEW: Check out these new beta commands that make deploying metadata easier than ever: * `deploy metadata validate`: Validate a metadata deployment without actually executing it. * `deploy metadata quick`: Quick deploy a validated deployment to an org. * `deploy metadata resume`: Resume watching a deploy operation. * `deploy metadata cancel`: Cancel a deploy operation. * `deploy metadata report`: Check the status of a deploy operation. The `validate` and `quick` commands work together. They're useful if the deployment to your production org takes several hours and you don’t want to risk a failed deploy. You first validate a deployment to verify whether it will succeed, without actually deploying the metadata to your org. The command returns a job ID, which you then pass to the `quick` command to _actually_ deploy the metadata. The quick deploy takes less time because it skips running Apex tests, which ran as part of the validation. Let's look at some examples. Validate the deployment to the org with alias `my-prod-org` of all source files in the `force-app` directory: `sf deploy metadata validate --source-dir force-app --target-org my-prod-org` When the command completes, you can pass the displayed job ID to the `quick` command: `sf deploy metadata quick --job-id 0Af0x000017yLUFCA2` Use the `--async` flag on either command to run it asynchronously; the command still displays the job ID but immediately returns the control of the terminal to you. `sf deploy metadata validate --source-dir force-app --target-org my-prod-org --async` Resume watching the asynchronous command by passing the job ID to the `resume` command: `sf deploy metadata resume --job-id 0Af0x000017yLUFCA2` Cancel a deploy operation that hasn't yet completed in the org using the `cancel` command. In this context, "deploy operations" include standard deploys, quick deploys, deploy validations, and deploy cancellations. `sf deploy metadata cancel --job-id 0Af0x000017yLUFCA2` Want to check the status of a deploy operation? Use the `report` command: `sf deploy metadata report --job-id 0Af0x000017yLUFCA2` Lost the job ID? Don't panic! Specify the `--use-most-recent` flag with any command that takes a job ID: `sf deploy metadata resume --use-most-recent` See the `--help` of each command for more interesting flags and examples. ## 1.26.0 (May 5, 2022) * NEW: Manage scratch orgs and sandboxes with these new beta commands: * `env create scratch` * `env resume scratch` * `env delete scratch` * `env create sandbox` * `env resume sandbox` * `env delete sandbox` Use the `create` commands to create scratch orgs and sandboxes. While executing, they display running information about the background processes, such as sending requests, deploying org settings, and so on. Pretty cool knowing what's going on behind the scenes, no? Use the `resume` command if the original `create` command times out, or you specified the `–async flag` to run it asynchronously. Use the `delete` commands to, yep, you guessed it, delete a scratch org or sandbox! Let's run through a few scratch org examples to see the new commands in action. Create a scratch org from a definition file, set it as your default environment, give it an alias, and use the Dev Hub with alias `DevHub`: `sf env create scratch --definition-file config/project-scratch-def.json --set-default --alias myscratch --target-dev-hub DevHub` Create a Developer Edition scratch org using your default Dev Hub and give it an alias: `sf env create scratch --edition=developer --alias anotherscratch` Create a scratch org asynchronously. The command returns control to you right away and displays a job ID: `sf env create scratch --edition=developer --alias happyscratch --async` Resume the scratch org creation by passing the job ID to the `resume` command: `sf env resume scratch --job-id 2SR3u0000008fBDGXD` Delete the scratch org when you’re done with it: `sf env delete scratch --target-org happyscratch` The sandbox commands work much the same, except they have a few additional flags specific to sandboxes, such as `–license-type` and `–name`. See the `–-help` for all the flags. ## 1.25.2 (April 28, 2022) * CHANGE: We no longer support v12 of Node.js because of its fast approaching end-of-life ([April 30, 2022](https://nodejs.org/en/about/releases/)). We bundle Node.js in each operating system-specific Salesforce CLI installer. We include the Active LTS version of Node.js and update it in tandem with the Node.js release schedule. If you prefer to install Salesforce CLI using `npm`, we recommend you also use the Active LTS version of Node.js. ## 1.24.0 (April 21, 2022) Starting today, `sf` commands that we're actively working on, but are publicly available, are marked with a beta tag. We can update these beta commands in any future release. While we try not make any breaking changes in these beta commands, we reserve the right to do so without warning. This process allows us to iteratively build `sf` and get feedback from you as we go. As soon as we've finished working on a beta command, and we've provided ample time for improvements based on your feedback, we'll remove the beta tag. At that point, the command is GA and follows our [deprecation policy](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/sfdx_dev_cli_deprecation.htm). A few additional notes: * All beta `sf` commands have a corresponding `sfdx` command. * We don't recommend that you use the beta commands in your CI/CD scripts. * We do recommend that you use and test the beta commands in your day to day CLI work and give us feedback early and often by entering [GitHub issues](https://github.com/forcedotcom/cli/issues). * `sf` commands that support GA products and have no `sfdx` equivalents, such as Salesforce Functions, will never be marked as beta. These commands are GA from the moment the product itself goes GA and are subject to our [deprecation policy](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/sfdx_dev_cli_deprecation.htm). * New `sf` commands are marked with a beta tag by default, unless there are no `sfdx` equivalents and they support a GA product. --- * CHANGE: These commands are now marked beta; they behave the same as before: * `sf deploy metadata` * `sf retrieve metadata` ## 1.23.0 (April 14, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.22.0 (April 7, 2022) * CHANGE: As part of the fix for [GitHub issue #1408](https://github.com/forcedotcom/cli/issues/1408), Salesforce CLI now uses rotating log files. By default, every day at midnight the CLI makes a backup copy of the log file and then clears out its entries to start afresh. This new behavior ensures that the log file doesn't get too big. We keep backups for the past two days along with the current day’s logs. Change the default behavior with these new environment variables: * SF_LOG_ROTATION_PERIOD: How often a new log file is created. For example, a value of `1d` means a new log file is created daily, at midnight. A value of `2w` creates a new file every 2 weeks. See the _period_ entry in [this table](https://github.com/forcedotcom/node-bunyan#stream-type-rotating-file) for other options. Default value is `1d`. * SF_LOG_ROTATION_COUNT: Number of backup files to keep. Default value is `2`. For example, if you choose a rotation period of 2 weeks and a count of 2, you always have backups for the four weeks before the first entry in the current log. * CHANGE: We've changed the names of these configuration variables to better fit into the unified CLI world: |Old Name|New Name| |--------|--------| |apiVersion|org-api-version| |disableTelemetry|disable-telemetry| |instanceUrl|org-instance-url| |maxQueryLimit|org-max-query-limit| |restDeploy|org-metadata-rest-deploy| The new names [interoperate with the equivalent `sfdx` config values](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_sf_and_sfdx.htm), just like the old names did. But you can no longer use the old names. For example: * If you run `sfdx config:set apiVersion=54.0`, then `org-api-version` is also set to `54.0` in `sf`. * If you run `sf config set org-api-version=54.0`, then `apiVersion` is also set to `54.0`in `sfdx`. * If you run `sf config set apiVersion=54.0`, you get an error. Run `sf config set org-api-verison=54.0` instead. We're in the process of updating the [documentation](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_sf_and_sfdx.htm). ## 1.20.0 (March 31, 2022) * NEW: We've added the following new flags to the `deploy metadata` command that mirror similar functionality in the `sfdx force:source:deploy` command: * `--api-version`: API version to use when deployng. * `--dry-run`: Validate the deploy and run Apex tests but don't save to the org. * `--ignore-errors`: Ignore any errors and don't roll back deployment. * `--ignore-warnings`: Ignore warnings and allow a deployment to complete successfully. * `--tests` : Apex tests to run when `--test-level` is `RunSpecifiedTests`. * `--verbose`: Show verbose output of the deploy result. * NEW: Get JSON output when running the `env var get` command with the `--json` flag. ## 1.19.0 (March 24, 2022) * NEW: Salesforce CLI can now read your mind. Okay, not really, but the `sf` executable got a lot smarter in this release. You can now enter command fragments in any order, and the CLI figures out what you mean. For example, let's say you want to log into an org using JWT but you forgot the exact command. All of the following commands work without returning any `command not found` errors: ```bash sf login org jwt sf org login jwt sf jwt org login ``` But wait, there’s more. If you remember only part of a command, run the partial command anyway to see a handy list of all the commands that contain that part. Use arrows to highlight the one you want, then press return to choose it. For example, let's say you want to list all your environments, but can't remember the exact command name. Try this: ```bash sf list ? Which of these commands do you mean (Use arrow keys) > config list > env list > env logdrain list > env var list ``` The command to list your environments is, wait for it... `sf env list`! To narrow down a long list of possible commands, provide a flag. For example, if you run `sf list –all`, it displays only the `env list` command because it's the only one that has the `–all` flag. Each command still has a canonical signature, which we use in the `–help` examples and to organize the [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_unified.htm). Here's a fun activity: discover all the cool `sf` commands by simply entering keywords at the command line! * NEW: We've improved how the interactive `sf deploy` command handles expired scratch orgs. As before, the command refers to the `target-org` configuration variable when prompting you for the org to which to deploy. If, however, the scratch org it points to has expired, the command now asks if you want to deploy to a different org. If you do, the command gives you a list of orgs to choose from, and then asks if you want to set it as your default. Nice. ## 1.18.0 (March 17, 2022) * NEW: Add a Heroku user as a collaborator on a compute environment with the new `env compute collaborator add` command. Specify the Heroku user's email address with the `--heroku-user` flag. After running the command, you can attach [Heroku add-ons](https://elements.heroku.com/addons) to the compute environment. For example: `sf env compute collaborator add --heroku-user me@example.com` ## 1.17.0 (March 10, 2022) * FIX: We've improved the error messages returned when you use one of these Salesforce Functions commands to run a JavaScript or TypeScript function that encounters unexpected data: * `run function start` * `run function start local` * `run function start container` The improved error messages provide more information about the problem to help you understand what went wrong and how to proceed. ## 1.16.0 (March 3, 2022) * CHANGE: When you run `sf update`, we now warn you that it has no effect if you installed `sf` using the `sfdx` installer. In this case, to update `sf`, run `sfdx update`. ## 1.15.0 (Feb 24, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.14.0 (Feb 17, 2022) * NEW: Easily update `sf` to any available version with the new `--version` flag of the `update` command. Not sure which versions are available? Use the new `--available` flag to list them. The output also handily includes the location of the version, either local (because you've previously installed it) or out there in the cloudy world. There's no need to download remote versions, the `sf update --version` command does it for you. We've even added an `--interactive` flag; use your cursor to choose the version from a list. For example: ```bash sf update --version 1.12.0 sf update --interactive sf update --available ``` Updating to the current or release candidate versions using the `stable` or `stable-rc` tags works as before: ```bash sf update stable-rc ``` NOTE: These update changes apply only if you installed `sf` with its installer. They don't apply if you installed `sf` with either the `sfdx` installer or `npm`. ## 1.12.0 (Feb 10, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.11.1 (Feb 3, 2022) * FIX: We fixed some under-the-hood bugs. ## 1.10.0 (Jan 27, 2022) * CHANGE: Docker is no longer required when you develop a Salesforce Function locally using the `run function start` command. Instead, you can build and run Functions on the host operating system, which results in a faster development cycle. If you want to continue using Docker for local Salesforce Functions development, use the new `run function local container` command. This command behaves the same as `run function start` did before this release. ## 1.9.1 (Jan 20, 2022) * NEW: Build and run a Salesforce Function in a container with the new `run function start container` command. * FIX: We've switched the HTTP library used by the [Salesforce Functions commands](https://github.com/salesforcecli/plugin-functions) to ensure compatibility with customer VPNs. ## 1.8.0 (Jan 13, 2022) * CHANGE: If the `info releasenotes display` command (alias `whatsnew`) can't find an exact match of the installed CLI version in the release notes, the command displays the notes for the closest version. The command behaves the same way if it can't find the exact version specified by the `–version` parameter in the release notes. ## 1.7.0 (Dec 23, 2021) NOTE: Because of the holidays, we're not publishing a new `stable-rc` release today or next week (Dec 30, 2021). We'll return to our regular weekly release schedule on Jan 6, 2022. (Wow, next year we'll be exactly 200 years away from the first every-digit-is-the-same year since 1111. Exciting stuff!) Happy holidays to our fabulous developer community, and see you next year! * NEW: Easily find the `sf` command or flag you want to execute with the new autocomplete feature. It works the same as standard autocomplete on a terminal: it's all about the TAB key. First type `sf` at the prompt and then press TAB twice to view the full list of topics and top-level commands. Then type the first letter of a topic or command, press TAB again, and the CLI autocompletes it as best it can. Autocomplete works similarly with flags: after you've typed out a command, type a dash (`-`) then TAB twice to see the full list of available flags. Then type a letter and TAB to autocomplete a specific flag. Play around with it and you'll get the hang of it, don't worry! To install autocomplete, run `sf autocomplete` and follow the instructions for your particular environment. For example, on macOS with the bash shell, you run this command, which updates your `.bashrc` file: `printf "eval $(sf autocomplete:script bash)" >> ~/.bashrc; source ~/.bashrc` Autocomplete on `sf` is currently supported only on the macOS and Linux operating systems and the Bash shell. * NEW: Quickly catch up on the new and changed features in any Salesforce CLI release with the new `info releasenotes display` command (alias `whatsnew`). By default, the command displays the release notes for the Salesforce CLI version that's currently installed. Use the `--version|-v` flag to specify a specific CLI version or a tag, such as `stable-rc`. For example: ```bash sf whatsnew sf whatsnew --version stable-rc sf whatsnew -v 1.6.0 ``` ## 1.6.0 (Dec 16, 2021) * CHANGE: Installing the `sfdx` executable with the `npm install sfdx-cli -g` command no longer installs the `@salesforce/cli` package, which corresponds to the `sf` executable. To install `sf` via npm, run this command: `npm install @salesforce/cli -g`. Installing Salesforce CLI with the installers and TAR files hasn't changed; they still install both the `sfdx` and `sf` executables. ## 1.5.2 (Dec 9, 2021) * NEW: Build and run a Salesforce Function locally with the new `sf run function start local` command. ## 1.4.0 (Nov 18, 2021) * FIX: We fixed some under-the-hood bugs. ## 1.3.0 (Nov 11, 2021) * FIX: We improved the automatic installation of `sf` when you install `sfdx` using the operating system-specific installers and TAR files. ## 1.2.0 (Nov 4, 2021) * FIX: We fixed a bug that prevented `sfdx update` from also updating `sf` to its latest version. ## 1.1.5 (Oct 28, 2021) * FIX: We fixed some under-the-hood bugs. ## 1.1.0 (Oct 21, 2021) * FIX: We fixed some under-the-hood bugs. ## 1.0.4 (Oct 7, 2021) Welcome to the first GA release of the new `sf` executable of Salesforce CLI! Salesforce CLI is a bundle of two executables: `sf` and `sfdx`. We first launched `sfdx` for you to develop and test your apps more easily on Salesforce Platform. But if you want to work across all Salesforce clouds, `sfdx` doesn’t provide all the commands you need. With `sf`, we're bringing together a cross-cloud set of commands that streamline how you build and deploy across Salesforce. See [Get Started with CLI Unification](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_sf_intro.htm) for more information about the `sf` executable, such as how it works with `sfdx`, a mapping of the available `sf` commands to their equivalent `sfdx` commands, and more. ### Installation Notes If you've already installed Salesforce CLI and are using `sfdx` commands, update the CLI to the latest version to also get `sf`: sfdx update NOTE: If you haven't already, [uninstall the old `salesforcedx` plug-in](../sfdx/README.md#71063-june-17-2021) to ensure the update succeeds. Verify that you can use `sf` by running the `help` command, which lists the version and top-level topics: sf help You can also install `sf` with npm: npm install @salesforce/cli --global See [Install sf](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_sf_install.htm) for other installation options and troubleshooting information. ### Documentation We've enhanced the command-line help to include additional information. As a result, the help can get long, so we've also changed the behavior of the flags: * `-h` : Displays a subset of the full help: short command and flag descriptions and command usage. Great for quick reference. * `--help` : Displays the `-h` content plus longer command and flag descriptions, examples, and the configuration and environment variables that affect the command. As far as the online documentation: * The [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_top.htm) contains reference information about both `sf` and `sfdx` commands. * For now, the [Salesforce DX Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm) continues to use only the `sfdx` executable in its examples. * The [Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_sf_intro.htm) contains all the online information about `sf` in a new Get Started section. ### Feedback We want to hear from you! Enter any issues you encounter with the `sf` executable and feature requests in [Issues tab of this GitHub repo](https://github.com/salesforcecli/cli/issues). ================================================ FILE: releasenotes/sfdx/README.md ================================================ # Salesforce CLI Release Notes (sfdx Commands) **IMPORTANT ANNOUNCEMENT, PLEASE READ**: We no longer update `sfdx` (v7); the last stable version is `7.209.6`. The current release is now `sf` (v2); read the release notes [here](../README.md). See [this note](./README.md#72096-july-13-2023-stable) for additional details. --- Here are the new and changed features in recent updates of the `sfdx` executable of Salesforce CLI. We publish a new `stable` version of `sfdx` on Thursdays. At the same time we also publish the `stable-rc` release candidate. The release candidate contains changes that will likely be in the final weekly version. Run `sfdx version` to display the version installed on your computer. Run `sfdx update` to update to the latest available stable version. Check out these other update options: * Run `sfdx update stable-rc` to update to this week's release candidate. To return to the stable version, run `sfdx update stable`. * Use the `--version` flag to update to an older version, such as `sfdx update --version 7.178.0`. * Use the `--available` flag to view all available older versions you can update to or `-interactive` to update interactively. If you use [autocomplete](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_autocomplete.htm), run `sfdx autocomplete --refresh-cache` after you update Salesforce CLI to ensure that autocomplete works correctly on any new commands. [Click here for the previous sfdx release notes.](./v50.md) Want to check out the new `sf` executable of Salesforce CLI? [Click here for the release notes.](../sf/README.md) Additional documentation: * [Salesforce CLI Command Reference (sfdx)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm) * [Salesforce DX Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm) * [Salesforce CLI Plugin Developer Guide (sfdx)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins.htm) * [Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm) ## 7.209.6 (July 13, 2023) [stable] **IMPORTANT ANNOUNCEMENT, PLEASE READ**: We no longer update `sfdx` (v7); the last stable version is `7.209.6`. You can keep using `sfdx` (v7) if you want, but it won't contain new features or bug fixes. And we no longer update this page. To continue getting weekly CLI updates, you must move to `sf` (v2). It's easy: simply uninstall `sfdx` and then install `sf`. See the new [Move from `sfdx` (v7) to `sf` (v2)](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_move_to_sf_v2.htm) section of the Setup Guide for details, including how to update your continuous integration (CI) scripts. We also updated the entire Setup Guide to assume you're using `sf` (v2) and the `sf`-style CLI commands and configuration. The `sf` (v2) Release Notes are [here](../README.md); start checking that page for information about our weekly Salesforce CLI releases. For context and information about this change, see [this blog post](https://developer.salesforce.com/blogs/2023/07/salesforce-cli-sf-v2-is-here). -------------------------------------------- * FIX: When you run `org delete scratch | sandbox` to delete your default org, the CLI now also unsets the `target-org` configuration variable (if set) and any aliases which point to the deleted org. (sfdx-core PR [#874](https://github.com/forcedotcom/sfdx-core/pull/874)) * FIX: The `pacakge version create` command now correctly displays an error if the `definitionFile` parameter of `packageDirectories` in the `sfdx-project.json` file is set to an incorrect file location. Previously the command would fail silently. (GitHub issue [#2193](https://github.com/forcedotcom/cli/issues/2193), plugin-packaging PR [#364](https://github.com/salesforcecli/plugin-packaging/pull/364)) ## 7.208.10 (July 6, 2023) * NEW: Specify the value of the `sourceApiVersion` property in the generated `sfdx-project.json` project file with the new `--api-version` flag of the `project generate` command. The flag value overrides the `org-api-version` configuration variable, if set. If neither the flag nor the config var is set, then the `sourceApiVersion` property is set to the default value. For example: ```bash sfdx project generate --name myFabProject --api-version 58.0 ``` (GitHub issue [#1939](https://github.com/forcedotcom/cli/issues/1939), plugin-templates PR [#150](https://github.com/salesforcecli/plugin-templates/pull/150)) * NEW: Include deleted records and archived activities when you run a SOQL query with the `data query` command by specifying the new `--all-rows` Boolean flag. This feature is equivalent to using the [ALL ROWS keyword when executing a SOQL query from Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_query_all_rows.htm). For example: ```bash sfdx data query --query "SELECT Id, Name, Account.Name FROM Contact" --all-rows ``` (GitHub issue [#1959](https://github.com/forcedotcom/cli/issues/1959), plugin-data PR [#602](https://github.com/salesforcecli/plugin-data/pull/602)) * NEW: When using the [pre-deployment string replacement feature](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_string_replace.htm), you can now specify that if an environment variable isn’t set, then _remove_ a string from the source file. Use the new `allowUnsetEnvVariable` property together with the `replaceWithEnv` property in the `replacements` section of your `sfdx-project.json` file. In this example, if the environment variable SOME_ENV_THAT_CAN_BE_BLANK isn’t set, the string `myNS__` in the `myClass.cls` file is removed when the file is deployed. If the environment variable is set to a value, then that value replaces the `myNS__` string. ```json "replacements": [ { "filename": "/force-app/main/default/classes/myClass.cls", "stringToReplace": "myNS__", "replaceWithEnv": "SOME_ENV_THAT_CAN_BE_BLANK", "allowUnsetEnvVariable": true } ] ``` (GitHub issue [#2070](https://github.com/forcedotcom/cli/issues/2070), source-deploy-retrieve PR [#1019](https://github.com/forcedotcom/source-deploy-retrieve/pull/1019)) * FIX: We no longer display `Unexpected end of JSON input` when you run `org list` and one of your org authorization files is corrupt. We now display information for all orgs whose authorization files are fine, and a warning about the org that has the corrupt auth file. You can then delete the corrupt file and reauthorize the org. (GitHub issue [#2066](https://github.com/forcedotcom/cli/issues/2066), sfdx-core PR [#869](https://github.com/forcedotcom/sfdx-core/pull/869)) * FIX: We now provide a better error message if your `.forceignore` file includes only one of the two source files for MetadataWithContent metadata types and you try to deploy or retrieve the type. For example, the `MyClass` Apex class consist of two source files: `MyClass.cls` and `MyClass.cls-meta.xml`. If you want to ignore the `MyClass` Apex class, you must list both these files (or use an asterisk) in your `.forceignore` file. (GitHub issue [#2237](https://github.com/forcedotcom/cli/issues/2237), source-deploy-retrieve PR [#1020](https://github.com/forcedotcom/source-deploy-retrieve/pull/1020)) * FIX: Source tracking now correctly handles metadata type names that contain special characters, such as parentheses. (GitHub issue [#2212](https://github.com/forcedotcom/cli/issues/2212), source-tracking PR [#421](https://github.com/forcedotcom/source-tracking/pull/421)) * FIX: You can now set the `--instance-url` flag to a value that includes the `lightning` string as long as it's part of your actual My Domain name. For example, `https://mycompanyname-lightning.my.salesforce.com` is valid because the My Domain name itself includes `-lightning`. But we continue to not allow Lightning domain instance URLs, such as `https://mydomain.lightning.force.com`. (GitHub issue [#2241](https://github.com/forcedotcom/cli/issues/2241), plugin-auth PR [#732](https://github.com/salesforcecli/plugin-auth/pull/732)) * FIX: When a bulk data command, such as `data delete bulk`, fails, we now return an exit code of 1. Previously we incorrectly returned an exit code of 0. (GitHub issue [#1648](https://github.com/forcedotcom/cli/issues/1648), plugin-data PR [#601](https://github.com/salesforcecli/plugin-data/pull/601)) * FIX: Salesforce DX projects now support these metadata types: - ExtlClntAppSampleConfigurablePolicies (previously called ExtlClntAppMobileConfigurablePolicies) - ExtlClntAppSampleSettings (previously called ExtlClntAppMobileSettings) ## 7.207.4 (June 29, 2023) * NEW: Are you ready to convert your CI scripts to start using the `sf`-style commands? For example, you want to start using `org create scratch` to create a scratch org rather than `force:org:create`. If you're ready, use our new `dev convert script` command to convert most, if not all, of a script. First install the `plugin-dev` plugin. ```bash sf plugins install @salesforce/plugin-dev ``` Then pass your script file to the `dev convert script` command with the `--script` flag. ```bash sf dev convert script --script ./myScript.yml ``` The command scans your script file; when it finds an `sfdx` command or flag, it prompts whether you want to replace it with the new `sf` equivalent. Don't worry, the command doesn’t change your original file; instead it creates a file with the replacements, such as `myScript-converted.yml`. There's not always a one-to-one mapping between the `sfdx` and `sf` commands. As a result, `dev convert script` can convert a large portion of your script, but it likely can’t convert _all_ of it. In these cases, the command doesn't replace the `sfdx` command but instead adds a comment that starts with `#ERROR`. Finally, remember to test the converted script to make sure it's working as you expect! And check out the new [migration topics](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_migrate.htm) in the Salesforce CLI Reference Guide. * NEW: Run specific Apex tests when run `project delete source` with the new `RunSpecifiedTests` value of the `--test-level` flag. Just like the `project deploy start` command, specify the tests with the new `--tests` flag. Previously you were required to run either all local or org tests. For example: ```bash sf project delete source --metadata ApexClass:ExcitingClass --test-level RunSpecifiedTests --tests ApexClass:TestExcitingClass --target-org myorg ``` (GitHub issue [#2175](https://github.com/forcedotcom/cli/issues/2175), plugin-deploy-retrieve [#659](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/659)) * FIX: We now display a message with useful information when `org create scratch` fails due to a problem in the `settings` in the definition file. (GitHub issue [#2227](https://github.com/forcedotcom/cli/issues/2227), [sfdx-core](https://github.com/forcedotcom/sfdx-core/commit/39d1124804ee845533888878c9a7aeb2c0ed8c25)) * FIX: If you pass a config variable with a typo to `config unset`, the command asks if you meant the var with the correct spelling. If you answer `Y`, and the command is successful, it no longer displays the `Unknown config name` error. (GitHub issue [2019](https://github.com/forcedotcom/cli/issues/2019), plugin-settings PR [#291](https://github.com/salesforcecli/plugin-settings/pull/291)) * FIX: We reverted to the previous release of [`isomorphic-git`](https://isomorphic-git.org/) (a Salesforce CLI dependency) due to issues in version `1.24.0`. (GitHub issue [#2194](https://github.com/forcedotcom/cli/issues/2194), source-tracking PR [#417](https://github.com/forcedotcom/source-tracking/pull/417)) ## 7.206.6 (June 22, 2023) * CHANGE: We've removed all the `beta` aliases for the `force package` and `force package1` commands. As a result, you can no longer run commands like `force package beta version create`; use `package version create` instead. (plugin-packaging PR [#356](https://github.com/salesforcecli/plugin-packaging/pull/356)) * FIX: Running `project deploy start` with the environment variable `SFDX_USE_PROGRESS_BAR=false` now produces the expected output, similar to how the `force:source:deploy` worked. Specifically, the output doesn't include the bar graphics, it does include test completion and errors, and the output goes to stderr. (GitHub issue [#2103](https://github.com/forcedotcom/cli/issues/2103), plugin-deploy-retrieve PR [#662](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/662)) * FIX: When the `project deploy start` command fails, the output now wraps if your terminal is too narrow; previously the information was truncated. (GitHub issue [#2048](https://github.com/forcedotcom/cli/issues/2048 ), plugin-deploy-retrieve PR [#654](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/654)) * FIX: The `project retrieve start --package-name ` now retrieves only the specified package, and not the `unpackaged` package. (GitHub issue [#2148](https://github.com/forcedotcom/cli/issues/2148), plugin-deploy-retrieve PR [#658](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/658)) * FIX: Tables in command output are no longer truncated by default. As a result, when you run `org display --verbose`, for example, you now see the entire Access Token and Sfdx Auth Url values. (GitHub issue [#1974](https://github.com/forcedotcom/cli/issues/1974), sf-plugins-core PR [#318](https://github.com/salesforcecli/sf-plugins-core/pull/318)) * FIX: The `project retrieve start` command now correctly ignores files in non-default package directories if the files are listed in the `.forceignore` file. (GitHub issue [#2126](https://github.com/forcedotcom/cli/issues/2126), plugin-deploy-retrieve PR [#652](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/652), source-tracking PR [#412](https://github.com/forcedotcom/source-tracking/pull/412)) * FIX: Let's say you run `project deploy start --dry-run --metadata-dir` to validate a deploy of files in metadata format. You can now run `project deploy quick` on the validated job without errors. (GitHub issue [#2098](https://github.com/forcedotcom/cli/issues/2098), plugin-deploy-retrieve PR [#651](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/651)) * FIX: When you run `project deploy start|validate` and it fails due to insufficient code coverage, you now get a warning; previously it failed without explanation. (GitHub issue [#2179](https://github.com/forcedotcom/cli/issues/2179), plugin-deploy-retrieve PR [#656](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/656)) ## 7.205.6 (June 15, 2023) * FIX: The `project` commands that have the `-x|--manifest` flag, such as `project convert source` or `project deploy start`, correctly return an error if the specified manifest XML file is invalid. When possible, the commands also display information about what makes the file invalid. Previously the commands silently ignored the component with the invalid XML and incorrectly displayed a successful result. (source-deploy-retrieve PR [#996](https://github.com/forcedotcom/source-deploy-retrieve/pull/996)) * FIX: Running multiple commands that set an alias in parallel, such as `org create scratch --alias`, now correctly set the aliases for all the commands. Previously only one alias would be set. (GitHub issues [#1810](https://github.com/forcedotcom/cli/issues/1810) [#1806](https://github.com/forcedotcom/cli/issues/1806), sfdx-core PR [#842](https://github.com/forcedotcom/sfdx-core/pull/842)) * FIX: When running `project deploy start` with the `--json` flag, you can now also use the `--junit` and `--coverage-formatters` flags to output JUnit local test results. Previously the results weren't created if you specified `--json`. (GitHub issue [#2172](https://github.com/forcedotcom/cli/issues/2172), plugin-deploy-retrieve PR [#650](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/650)) * FIX: You can now successfully add a sibling sub-topic with the `dev generate command` command. Previously, if you tried to add a sibling topic when one already existed in the plugin, the first topic was overwritten in the plugin's `package.json` file. Now all works as expected and life is good again. (GitHub issue [#1805](https://github.com/forcedotcom/cli/issues/1805), plugin-dev PR [#335](https://github.com/salesforcecli/plugin-dev/pull/335)) Thank you [KevinGossentCap](https://github.com/KevinGossentCap) for contributing the fix! We love it. * FIX: When you run `package version create|update`, Salesforce CLI now resolves dependencies using the `branch` attribute of the `dependencies` key in the `sfdx-project.json` file and not the value of the `--branch` flag, if both are set. The value of the `--branch` flag is used only if the `branch` attribute isn't specified in `sfdx-project.json`. (GitHub issue [#2183](https://github.com/forcedotcom/cli/issues/2183), packaging PR [#310](https://github.com/forcedotcom/packaging/pull/310)) Woo-hoos and thanks to [David Polehonski](https://github.com/David-Polehonski) for finding the issue, and then contributing the fix. We love this one too. ## 7.204.6 (June 8, 2023) * NEW: Use the new `jobId` value to check the status of your Experience Cloud site during the site creation or site publish process. The site creation and site publish processes are async jobs that generate a `jobId`. When you run `community create` or `community publish`, we include the `jobId` in the command results. To check the status of your site creation or site publish job, query the BackgroundOperation object and enter the `jobId` as the Id. Experience Cloud site IDs start with `08P`. For example, if you ran the `community create` command on an org with alias `community`, use this command to query its status (replace `08Pxxx` with your specific `jobID`): ```bash sf data query --query "SELECT Status FROM BackgroundOperation WHERE Id = '08Pxxx'" --target-org community ``` Completed site creation and site publish jobs expire after 24 hours and are removed from the database. (plugin-community PR [#353](https://github.com/salesforcecli/plugin-community/pull/353)) * FIX: The `cmdt generate records` command correctly handles spaces and other non-alphanumeric characters in the CSV file when generating custom metadata type records. (GitHub issue [#2158](https://github.com/forcedotcom/cli/issues/2158), plugin-custom-metadata PR [#481](https://github.com/salesforcecli/plugin-custom-metadata/pull/481)) * FIX: The `project deploy start` command no longer return the error `Cannot read properties of null (reading 'replace')` when Apex tests fail. (GitHub issue [#2149](https://github.com/forcedotcom/cli/issues/2149), plugin-deploy-retrieve PR [#633](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/633)) * FIX: The `project deploy start` command now displays metadata component failures in its command-line output. (GitHub issue [#2008](https://github.com/forcedotcom/cli/issues/2008), plugin-deploy-retrieve PR [#623](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/623)) * FIX: We've fixed a number of issues related to Node.js v18.16.0. If you followed [our suggestions](https://github.com/forcedotcom/cli/issues/2125) for working around the issues, you can now return to the version of Node.js you were using before and update Salesforce CLI to the latest version. (GitHub issue [#2125](https://github.com/forcedotcom/cli/issues/2125), source-deploy-retrieve PR [#975](https://github.com/forcedotcom/source-deploy-retrieve/pull/975)) ## 7.203.6 (June 1, 2023) * NEW: We now group the multiple flags of `project deploy|retrieve start` and `org create scratch` in the `-h|--help` output so you can easily find that special flag you love so much. For example, we group the testing flags of `project deploy start` under TEST FLAGS. For `org create scratch`, we group the flags that override options in the scratch org definition file under DEFINITION FILE OVERRIDE FLAGS. (plugin-deploy-retrieve PR [#626](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/626), plugin-org [#685](https://github.com/salesforcecli/plugin-org/pull/685)) * NEW: Retrieve source files from your org into a directory other than the defined package directories with the new `--output-dir` (`-r`) flag of `project retrieve start`. If the output directory matches one of the package directories in your `sfdx-project.json` file, the command fails. (plugin-deploy-retrieve PR [#627](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/627)) * NEW: Salesforce DX projects now support the ScoreCategory metadata type. * FIX: You can now generate a custom field of type `Number` on an object using the `schema generate field` command. (GitHub issue [#2142](https://github.com/forcedotcom/cli/issues/2142), plugin-sobject PR [#292](https://github.com/salesforcecli/plugin-sobject/pull/292)) * FIX: The description for the `--test-level` flag of the `project deploy start|validate` commands in their `--help` correctly refers to the `--tests` flag; previously it mentioned the non-existent `--run-tests` flag. (GitHub issue [#2117](https://github.com/forcedotcom/cli/issues/2117), plugin-deploy-retrieve PR [#622](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/622)) * FIX: Deleting a single custom label component with the `project source delete` command, or with one of the destructive changes flags of `project deploy start` command, no longer deletes the entire `CustomLabels.labels-meta.xml` file. (GitHub issue [#2118](https://github.com/forcedotcom/cli/issues/2118), plugin-deploy-retrieve PR [#613](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/613)) * FIX: Get JSON output from the `sfdx plugins` command with the new `--json` flag. (GitHub issue [#267]( https://github.com/forcedotcom/cli/issues/267), oclif plugin-plugin PR [#609](https://github.com/oclif/plugin-plugins/pull/609)) ## 7.202.6 (May 25, 2023) * NEW: You can now specify these two scratch org definition file options as command-line flags when you run `org create scratch`: * `--admin-email`: Email address that's applied to the org's admin user. Equivalent to the `adminEmail` option in the scratch org definition file. * `--source-org`: 15-character ID of the org whose shape the new scratch org is based on. Equivalent to the `sourceOrg` option in the scratch org definition file. As always, if you set the option in the scratch org definition file, and also specify its equivalent flag, the flag overrides the defintion file setting. For example, let's say you set `adminEmail` in the scratch org definition file to `milo@tollbooth.com`. When you run this command, however, the scratch org admin's email address is actually set to `tock@phantom.com`: ```bash sf org create scratch --definition-file config/project-scratch-def.json --admin-email tock@phantom.com --target-dev-hub DevHub ``` (GitHub Feature Request [#2130](https://github.com/forcedotcom/cli/issues/2130), plugin-org PR [#681](https://github.com/salesforcecli/plugin-org/pull/681)) * NEW: Salesforce DX projects now support the UserAccessPolicy metadata type. * CHANGE: the `project deploy` commands now leave the `--test-level` flag undefined by default and let the org decide what tests run. If you don't specify the flag: - Non-production orgs don't run any tests. - Production orgs run tests if the deployment includes Apex classes or triggers. * FIX: We cleaned up the `--help` for the `project deploy start` command around specifying multiple Apex tests or code coverage formats with the `--tests` and `--coverage-formatters` flags. You no longer use a comma-separated list; instead, specify the flags multiple times or separate the values with spaces. (GitHub issue [#2117](https://github.com/forcedotcom/cli/issues/2117), plugin-deploy-retrieve PRs [#609](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/609) and [#662](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/622)) * FIX: We updated the `--help` for `org logout` to clarify that you don't get a list of orgs to interactively log out of if you've set your default org in your environment, such as with the `target-org` config variable. (GitHub issue [#2128](https://github.com/forcedotcom/cli/issues/2128), plugin-auth PR [#696](https://github.com/salesforcecli/plugin-auth/pull/696)) * FIX: The `orgID` value in the JSON output resulting from running `sf org create scratch --json` now contains the actual scratch org ID (starts with 00D) rather than the ScratchOrgInfo record ID (starts with 2SR). (GitHub issue [#2131](https://github.com/forcedotcom/cli/issues/2131), plugin-org PR [#675](https://github.com/salesforcecli/plugin-org/pull/675)) * FIX: All commands now know about the `org-metadata-rest-deploy` configuration variable, which is the new `sf`-style name for the `restDeploy` configuration variable. (GitHub issue [#2127](https://github.com/forcedotcom/cli/issues/2127), sfdx-core PR [#834](https://github.com/forcedotcom/sfdx-core/pull/834), plugin-signups PR [#276](https://github.com/salesforcecli/plugin-signups/pull/276)) * FIX: You can now run `project deploy start --metadata-dir`, which deploys source in metadata format, from outside a Salesforce DX project. Similarly, `project retrieve start --target-metadata-dir` also works outside of a project. (GitHub issue [#2089](https://github.com/forcedotcom/cli/issues/2089), plugin-deploy-retrieve PR [#619](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/619)). * FIX: You can now run `project retrieve start --package-name` on an org that doesn't have source-tracking enabled. (GitHub issue [#2091](https://github.com/forcedotcom/cli/issues/2091), plugin-deploy-retrieve PR [#619](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/619)) * FIX: When you run `project deploy start` without any of the flags that specify exactly what you want to deploy (such as `--source-dir`, `--manifest`, or `--metadata`), and nothing is deployed, the command now exits with a `0` code. Previously it exited with a `1` code. (GitHub discussion [#2065](https://github.com/forcedotcom/cli/discussions/2065), plugin-deploy-retrieve PR [#619](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/619)) ## 7.201.6 (May 18, 2023) * NEW: Autocomplete now works on Windows [PowerShell](https://learn.microsoft.com/en-us/powershell/)! Partially type a Salesforce CLI command or flag, then press Tab to see all the available commands or flags. Install the feature with these steps: 1. From a PowerShell window, run `sfdx autocomplete powershell`. 2. Follow the displayed instructions. 3. If autocomplete doesn’t work immediately after installation, run `sfdx autocomplete --refresh-cache`. Then open a new PowerShell window. Your work-life on Windows just got a little easier, how great is that? * NEW: When the `project generate manifest` command runs into an unknown metadata type, such as from a misspelled metadata file, the error now includes handy suggestions for one or more similar metadata types that the command _does_ know about. (source-deploy-retrieve PR [#948](https://github.com/forcedotcom/source-deploy-retrieve/pull/948)) * FIX: The `project deploy|retrieve start` commands now support these metadata types: * AIScoringModelDefinition * AIScoringModelDefVersion * SkillType * FIX: The JUnit test results after a successful execution of `project deploy start --junit` no longer include an empty failure tag. Many thanks to [Robin Windey](https://github.com/R0Wi) who contributed the fix. We love it, and hope to see more from you and the community! (GitHub issue [#2076](https://github.com/forcedotcom/cli/issues/2076), plugin-deploy-retrieve PR [#610](https://github.com/salesforcecli/plugin-deploy-retrieve/pull/610)) * FIX: If a deploy or retrieve encounters a `Socket connection timeout` error, the command now keeps retrying the deploy up to the retry limit. (GitHub issue [#2086](https://github.com/forcedotcom/cli/issues/2086), source-deploy-retrieve PR [#957](https://github.com/forcedotcom/source-deploy-retrieve/pull/957)) * FIX: We've improved the error message when you specify an invalid value for a flag of type `duration`, such as the `--wait` flag of `project deploy start`. (GitHub issue [#2109](https://github.com/forcedotcom/cli/issues/2109), sf-plugins-core PR [#287](https://github.com/salesforcecli/sf-plugins-core/pull/287)) * FIX: The `apex test run` command now correctly returns an error if you pass `-1` to its `--wait` flag. Previously the command would ignore the value and wait for the default 1 minute. The minimum value for this flag is `0`. (GitHub issue [#2110](https://github.com/forcedotcom/cli/issues/2110), plugin-apex PR [#116](https://github.com/salesforcecli/plugin-apex/pull/116)) * FIX: The `--license-type` flag of `org create sandbox` is now playing nice. In particular, its default value doesn't override the `licenseType` setting in the sandbox definition type when you don't specify the flag. And you no longer get an error when you specify both the flag and the `licenseType` definition file option. (GitHub issue [#2026](https://github.com/forcedotcom/cli/issues/2026), plugin-org [#667](https://github.com/salesforcecli/plugin-org/pull/667)) * FIX: String replacements before deploying metadata to the org are now working consistently on Windows, regardless of the shell you use. Special thanks to [micha79x](https://github.com/micha79x) for an excellent repo that reproduced the problem, and for doing most of the detective work. (GitHub issue [#1885](https://github.com/forcedotcom/cli/issues/1885), source-deploy-retrieve PR [#958](https://github.com/forcedotcom/source-deploy-retrieve/pull/958)) * FIX: The `dev generate command` and `dev generate field` commands now work correctly on Windows. (GitHub issue [#2051](https://github.com/forcedotcom/cli/issues/2051), plugin-dev PR [#317](https://github.com/salesforcecli/plugin-dev/pull/317)) ## 7.200.7 (May 11, 2023) * FIX: We now bundle Node.js version 18.15.0 in the installers. When we upgraded to 18.16.0, we saw issues around source conversion, deployment, and retrieval. If you install with `npm`, we recommend you not use Node.js 18.16.0 at this time. See [this pinned issue](https://github.com/forcedotcom/cli/issues/2125) for details. * FIX: We fixed the `directoryName` property for these two metadata types (associated with OAuth and mobile policies) in Salesforce CLI's metadata registry: ExtlClntAppOauthConfigurablePolicies and ExtlClntAppMobileConfigurablePolicies. (SDR PR [#947](https://github.com/forcedotcom/source-deploy-retrieve/pull/947)) * FIX: When you install a Salesforce CLI plugin, the CLI now validates that the package name is a valid npm package. This validation prevents accidents and increases security. (GitHub issue [#594](https://github.com/oclif/plugin-plugins/issues/594), oclif plugin-plugin PR [#597](https://github.com/oclif/plugin-plugins/pull/597)) * FIX: We've added a warning when you run `force:org:create` to say that it's been replaced by these two commands: `org create scratch` or `org create sandbox`. (plugin-org PR [#668](https://github.com/salesforcecli/plugin-org/pull/668)) * FIX: The `package1 version list` command now displays all results, not just the first 2000. (GitHub issue [#2073](https://github.com/forcedotcom/cli/issues/2073), packaging PR [#277](https://github.com/forcedotcom/packaging/pull/277)) ## 7.199.7 (May 4, 2023) * CHANGE: After you run `org login web` (`auth:web:login`) and log into your org, you're now redirected to a web page that displays either success or failure, depending on whether you were able to log in successfully. You're no longer redirected to Salesforce's [frontdoor.jsp page](https://help.salesforce.com/s/articleView?id=sf.security_frontdoorjsp.htm&type=5). (sfdx-core PR [#811](https://github.com/forcedotcom/sfdx-core/pull/811)) * FIX: The `force:source:push --json` command now produces the correct JSON output to stdout when the command fails due to a conflict. (GitHub issue [#2095](https://github.com/forcedotcom/cli/issues/2095), plugin-source PR [#828](https://github.com/salesforcecli/plugin-source/pull/828)) * FIX: Salesforce CLI no longer creates massive log files when certain criteria are met. (GitHub issues [#1942](https://github.com/forcedotcom/cli/issues/1942) and [#1408](https://github.com/forcedotcom/cli/issues/1408), sfdx-core PR [#818](https://github.com/forcedotcom/sfdx-core/pull/818)) ## 7.198.6 (April 27, 2023) * NEW: When you create a scratch org with `org create scratch`, you specify a definition file that contains options or use the` --edition` flag to specify the one required option. For either method, you can now also use these flags; if you use them with `--definition-file`, they override their equivalent option in the scratch org definition file: * `--description` * `--name` (equivalent to the `orgName` option) * `--username` * `--release` * `--edition` Note that now you can use `--definition-file` and `--edition` in a single command; previously you had to pick one or the other. If you want to set options other than the preceding ones, such as org features or settings, you must use a definition file. In this example, the command uses a scratch org definition file but overrides its `edition` and `description` options: ```bash sfdx org create scratch --definition-file config/project-scratch-def.json --edition enterprise --description "Enterprise Edition scratch org" --target-dev-hub DevHub --set-default ``` In this example, the command specifies all the options at the command line: ```bash sfdx org create scratch --edition enterprise --description "Enterprise Edition scratch org" --name "My Company" --target-dev-hub DevHub --set-default ``` (GitHub Feature Request [#2016](https://github.com/forcedotcom/cli/issues/2016), plugin-org PR [#641](https://github.com/salesforcecli/plugin-org/pull/641)) * CHANGE: Instead of bundling [plugin-lwc-test](https://github.com/salesforcecli/plugin-lwc-test) in the core Salesforce CLI, we now automatically install it the first time you run one of its commands: * `force lightning lwc test create` * `force lightning lwc test run` * `force lightning lwc test setup` Because not all our customers regularly test Lightning web components, we decided to make the plugin a just-in-time one. Note that this change applies only to _new_ Salesforce CLI installations. If the plugin is already installed in your Salesforce CLI, there's no change. NOTE: If you use these commands, you must use version 16 of Node.js at this time due to an indirect dependency on `sa11y` which doesn't yet support version 18, the current LTS. See [this feature request](https://github.com/salesforce/sa11y/issues/376) for `sa11y` to support Node.js 18. See more information about Node.js versions [here](https://github.com/forcedotcom/cli/issues/1985). * FIX: If the `project deploy start` command fails, source-tracking information is updated correctly. (GitHub issue [#2057](https://github.com/forcedotcom/cli/issues/2057), source-tracking PR [#368](https://github.com/forcedotcom/source-tracking/pull/368)) * FIX: The `cmdt generate records` command correctly generates custom metadata type records and no longer returns the error `ModuleLoadError: [MODULE_NOT_FOUND]`. (GitHub issue [#2058](https://github.com/forcedotcom/cli/issues/2058), plugin-custom-metadata PR [#445](https://github.com/salesforcecli/plugin-custom-metadata/pull/445)) * FIX: Retrieving a reactivated PicklistValue metadata type no longer returns an erroneous error message. (GitHub issue [#960](https://github.com/forcedotcom/cli/issues/960), source-tracking PR [#960](https://github.com/forcedotcom/cli/issues/960)) ## 7.197.8 (April 20, 2023) * FIX: We've recently done a lot of work in the [source-deploy-retrieve](https://github.com/forcedotcom/source-deploy-retrieve) (SDR) library to address various issues that result in the error `Cannot read properties of undefined (reading 'something')`. These issues are often caused by metadata files being in an unexpected location or format. In addition to addressing these issues, we also now provide more useful errors with details about the name, type, and location of the file in your project that is causing the error. Our goal is to make it easier for you to find and fix the error if it's on your side, or quickly determine if it's actually a bug with Salesforce CLI. * FIX: The `sfdx apex run test` command now correctly runs Apex tests asynchronously by default. (GitHub issue [#2034](https://github.com/forcedotcom/cli/issues/2034), plugin-apex PR [#91](https://github.com/salesforcecli/plugin-apex/pull/91)) ## 7.196.6 (April 13, 2023) * NEW: We continue to [improve the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands. A [few weeks ago](./README.md#71932-march-23-2023) we started updating the commands in [plugin-source](https://github.com/salesforcecli/plugin-sobject) to the new `sf` styles; this week we finish up. The following existing commands have new names; both names work interchangeably. Some command flags also have new names, but just like the commands, both names work interchangeably. Note that the old names are deprecated, so we recommend you start using the new names as soon as you can. |Existing Command Name|New Command Name|Flag Name Changes| |-----|------|---| |`force:mdapi:convert`|`project convert mdapi`|
  • `--metadatapath` ==> `--metadata-dir`
  • `--outputdir` ==> `--output-dir`
  • `--rootdir` ==> `--root-dir`
  • New flag: `--api-version`
  • Deprecated flag: `--loglevel`
| |`force:source:convert`|`project convert source`|
  • `--outputdir` ==> `--output-dir`
  • `--packagename` ==> `--package-name`
  • `--rootdir` ==> `--root-dir`
  • `--sourcepath` ==> `--source-dir`
  • New flag: `--api-version`
  • Deprecated flag: `--loglevel`
      • | |`force:source:delete`|`project delete source`|
      • `--apiversion` ==> `--api-version`
      • `--checkonly` ==> `--check-only`
      • `--forceoverwrite` ==> `--force-overwrite`
      • `--noprompt` ==> `--no-prompt`
      • `--sourcepath` ==> `--source-dir`
      • `--targetusername` ==> `--target-org` (new short name `-o`)
      • `--testlevel` ==> `--test-level`
      • `--tracksource` ==> `--track-source`
      • Deprecated flag: `--loglevel`
          • | |`force:source:ignored:list`|`project list ignored`|
          • `--sourcepath` ==> `--source-dir`
          • Deprecated flag: `--loglevel`
          | |`force:source:manifest:create`|`project generate manifest`|
          • `--apiversion` ==> `--api-version`
          • `--fromorg` ==> `--from-org`
          • `--includepackages` ==> `--include-packages`
          • `--manifestname` ==> `--manifest-name`
          • `--manifesttype` ==> `--manifest-type`
          • `--outputdir` ==> `--output-dir`
          • `--sourcepath` ==> `--source-dir`
          • Deprecated flag: `--loglevel`
          | |`force:source:tracking:clear`|`project delete tracking`|
          • `--apiversion` ==> `--api-version`
          • `--noprompt` ==> `--no-prompt`
          • `--targetusername` ==> `--target-org` (new short name `-o`)
          • Deprecated flag: `--loglevel`
          | |`force:source:tracking:reset`|`project reset tracking`|
          • `--apiversion` ==> `--api-version`
          • `--noprompt` ==> `--no-prompt`
          • `--targetusername` ==> `--target-org` (new short name `-o`)
          • Deprecated flag: `--loglevel`
          | We plan to deprecate the following existing commands in the future, although don't worry, they'll still be around for a while. Each existing command has an equivalent new command with almost the same functionality, except for what we note in the table. We suggest you start using the new commands as soon as possible. As always, run the new commands with the `--help` flag to see details and examples and new flag names. |Existing Command|New Equivalent Command|Functionality changes and additions| |---------------------------|----------------------|----| |`force:mdapi:deploy`|`project deploy start`|The `project deploy start` command works for _both_ source format and metadata format (mdapi) files. Use flags to specify the format you're deploying. For example, the `project deploy start` command deploys source formatted files by default, but you can use `--metadata-dir` to deploy metadata format files.| |`force:mdapi:deploy:cancel`|`project deploy cancel`|None.| |`force:mdapi:deploy:report`|`project deploy report\|resume`|The existing `force:mdapi:deploy:report` command does more than just report: it also resumes a deployment, which is confusing. We now provide two new commands for each task (`project deploy report` and `project deploy resume`) which is more intuitive.

          The new commands don't support the `--wait -1` existing flag (which means "wait forever"). Instead, specify a very large number with the new commands. | |`force:mdapi:retrieve`|`project retrieve start`|The `project retrieve start` command works for _both_ source format and metadata format (mdapi) files. Use flags to specify the format you're retrieving. For example, the `project retrieve start` command retrieves source formatted files by default, but you can use `--target-metadata-dir` to retrieve metadata format files.| |`force:mdapi:retrieve:report`|No equivalent|We removed this command.| |`force:source:deploy`|`project deploy start`|The new command always keeps track of your source if the org is enabled for source-tracking. If you don't want to use source tracking, create an org that doesn't have source tracking enabled.| |`force:source:deploy:cancel`|`project deploy cancel`|None.| |`force:source:deploy:report`|`project deploy report\|resume`|The `force:source:deploy:report` command does more than just report: it also resumes a deployment, which is confusing. We've now provide two new commands for each task (`project deploy report` and `project deploy resume`) which is more intuitive. | |`force:source:open`|`org open --source-file`|The `force:source:open` command is now the `--source-file` flag on the `org open` command. You can now also specify the browser.| |`force:source:pull`|`project retrieve start`|None.| |`force:source:push`|`project deploy start`|The new command doesn't support the `pushPackageDirectoriesSequentially` property of `sfdx-project.json`. The `force:source:push` command uses this property to deploy packages sequentially. If you need to deploy packages sequentially and in a specific order, use separate `project deploy start` commands in the desired order. | |`force:source:retrieve`|`project retrieve start`|The new command keeps track of your source if the org is enabled for source-tracking. If you don't want to use source tracking, create an org that doesn't have source tracking enabled.| |`force:source:status`|`project deploy\|retrieve preview`|We now provide two separate commands to preview what a deploy or a retrieve will do, which is more intuitive. These `preview` commands have the same flags as their non-preview commands, such as `project deploy start`. The `force:source:status` command shows both local and remote changes, which is confusing. | Finally, we removed these beta commands. |Removed Beta Command|Use This Command Instead| |----|----| |`force:source:beta:tracking:reset`|`project reset tracking`| |`force:source:beta:tracking:clear`|`project delete tracking`| |`force:mdapi:beta:convert`|`project convert mdapi`| Let's look at some examples. This command: ```bash sfdx force:source:deploy --metadata "ApexClass,CustomObject" --testlevel RunSpecifiedTests --runtests MyTests --targetusername my-scratch ``` Can be run this way: ```bash sf project deploy start --metadata ApexClass --metadata CustomObject --test-level RunSpecifiedTests --tests MyTests --target-org my-scratch ``` This command: ```bash sfdx force:source:delete --sourcepath force-app/main/default/flows --targetusername my-scratch --forceoverwrite --noprompt ``` Can be run this way: ```bash sf project delete source --source-dir force-app/main/default/flows --target-org my-scratch --force-overwrite --no-prompt ``` Have fun with these new commands! * FIX: Running the `force source convert` command on Windows on a directory with Digital Experiences in it no longer produces a `package.xml` file with invalid entries. (GitHub issue [#2014](https://github.com/forcedotcom/cli/issues/2014), SDR PR [#911](https://github.com/forcedotcom/source-deploy-retrieve/pull/911)) ## 7.194.1 (March 30, 2023) * FIX: Executing the `apex get log` command with the `--log-id` flag now correctly fetches the log with the specified ID. (GitHub issue [#2006](https://github.com/forcedotcom/cli/issues/2006), plugin-apex PR [#79](https://github.com/salesforcecli/plugin-apex/pull/79)) * FIX: The `--url-path-prefix` flag of the `community create` command is no longer required, which is the correct behavior. (GitHub issue [#2005](https://github.com/forcedotcom/cli/issues/2005), plugin-community PR [#303](https://github.com/salesforcecli/plugin-community/pull/303)) * FIX: Let's say you log into a Dev Hub org, and then log into a scratch org that's associated with it, but you created this scratch org from a different computer. Running `org list` on the first computer now correctly lists the scratch org and its expiration date in the appropriate section. (GitHub issue [#1941](https://github.com/forcedotcom/cli/issues/1941), sfdx-core PR [#775](https://github.com/forcedotcom/sfdx-core/pull/775)) * FIX: When you run `force:source:deploy --verbose` with the progress bar turned off (`SFDX_USE_PROGRESS_BAR=false`), we now display the deploy status with every poll. With this change, CI systems that have low output timeouts don't exit during long-running deploys in which the results aren't outputted for many minutes. (GitHub issue [#1839](https://github.com/forcedotcom/cli/issues/1839), plugin-source PR [#757](https://github.com/salesforcecli/plugin-source/pull/757)) * FIX: The `force source` commands now support the ExtlClntAppGlobalOauthSettings metadata type. ## 7.193.2 (March 23, 2023) * NEW: We continue to [improve the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands. We are slowly updating the commands in [plugin-source](https://github.com/salesforcecli/plugin-sobject) to the new `sf` styles; you'll see changes over the next few weeks. These are the new command names this week. For each command, you can still use colons instead of spaces, such as `org:list:metadata`. |Existing Command Name|New Command Name| |------------|-------------| |`force:mdapi:listmetadata`|`org list metadata`| |`force:mdapi:describemetadata`|`org list metadata-types`| These are the new flag names for the new command names listed above. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`. The `-a` short flag name is deprecated.|`--api-version`|Both commands. | |`--metadatatype`|`--metadata-type`|`force:mdapi:listmetadata`| |`--resultfile`|`--output-file`|Both commands| |`--targetusername`|`--target-org`, with new short flag name `-o`.|Both commands| This flag is deprecated and has no effect. |Deprecated Flag|Affected Existing Command| |---|---| |`--loglevel`|Both commands| Let's look at an example, such as this command: ```bash sfdx force:mdapi:listmetadata --metadatatype CustomObject --apiversion 57.0 --resultfile /path/to/outputfile.txt --targetusername my-org-alias ``` You can now run it this way using the `sf` style: ```bash sfdx org list metadata --metadata-type CustomObject --api-version 57.0 --output-file /path/to/outputfile.txt --target-org my-org-alias ``` The existing commands work exactly as before. But give this new stuff a try, we think you'll like it. * NEW: Open a Lightning Page from your local project in Lightning App Builder with the new `--source-file` flag of the `org open` command. For example: ```bash sfdx org open --source-path force-app/main/default/flexipages/Hello.flexipage-meta.xml --target-org my-org-alias --browser firefox ``` The new flag replaces the existing `force:source:open` command, which you can still use but you'll get those pesky deprecation warnings. The change is part of SCUIC ([Salesforce CLI Usability Improvement Campaign](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli)). Note that you now have more options; for example, you can open a page in Lightning App Builder and specify the browser, as shown in the previous example. * CHANGE: We changed the long name of the flag to specify a Dev Hub org from `--target-hub-org` to `--target-dev-hub` for these packaging commands: * `package:convert` * `package:create` * `package:delete` * `package:list` * `package:update` * `package:version:create` * `package:version:create:list` * `package:version:create:report` * `package:version:delete` * `package:version:displayancestry` * `package:version:list` * `package:version:promote` * `package:version:report` * `package:version:update We aliased the old long name to the new one, so nothing will break. But we highly recommend you update your scripts to use the new flag name. The short flag name (`-v`) didn't change. We made this change so the flag name matches the other `sfdx` commands. * FIX: We fixed the examples for the `sfdx apex run` command so they use the correct flag: `--file` instead of the incorrect `--apex-code-file`. (GitHub issue [#1999](https://github.com/forcedotcom/cli/issues/1999), plugin-apex PR [#71](https://github.com/salesforcecli/plugin-apex/pull/71)) ## 7.192.2 (March 16, 2023) * FIX: The `package version create` command now applies the `language` attribute from the scratch org definition file. (GitHub issue [#1921](https://github.com/forcedotcom/cli/issues/1921), packaging PR [#239](https://github.com/forcedotcom/packaging/pull/239)) ## 7.191.1 (March 9, 2023) These changes are in the Salesforce CLI release candidate. We plan to include these changes in next week's official release. This list isn't final and is subject to change. * NEW: We've made it easier for you to develop secure code by adding [Salesforce Code Analyzer](https://forcedotcom.github.io/sfdx-scanner/) as a "just-in-time" plugin. Simply type one of the commands, such as `sfdx scanner run`, and if the plugin isn't already installed, Salesforce CLI automatically installs the latest version. Then use the `sfdx scanner` commands to detect quality issues and security vulnerabilities in your code. As always, run a command with `--help` to see more information. And be sure to check the [prerequisites page](https://forcedotcom.github.io/sfdx-scanner/en/v3.x/getting-started/prerequisites/). * NEW: As part of [improving the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands so they work like the `sf` commands, we reconciled all `config` and `alias` commands in both executables into a single plugin: [plugin-settings](https://github.com/salesforcecli/plugin-settings). The commands work the same as before. Actually, some of the `config` commands work _better_ than before because you can now enter a slightly-misspelled configuration variable and the command prompts you with the correct name. Super handy if you forget the exact name of a config var. For example: ```bash $ sfdx config set version=57.0 ? Did you mean org-api-version? Yes Set Config =============================== | Name Value Success | ─────────────── ───── ─────── | org-api-version 57.0 true ``` We also deprecated the old names of the configuration variables in favor of the new `sf` ones. You can still set the old names, but we display a deprecation warning to nudge you towards the new names. We recommend that you start using the new names as soon as possible. Here's a summary: |Old Name|New Name| |---|---| |`apiVersion`|`org-api-version`| |`customOrgMetadataTemplates`|`org-custom-metadata-templates`| |`defaultdevhubusername`|`target-dev-hub`| |`defaultusername`|`target-org`| |`disableTelemetry`|`disable-telemetry`| |`instanceUrl`|`org-instance-url`| |`maxQueryLimit`|`org-max-query-limit`| |`restDeploy`|`org-metadata-rest-deploy`| ## 7.190.0 (Mar 2, 2023) **NOTE**: Due to various issues with the `7.189.x` releases candidates, and some `7.190` changes that snuck in early, we didn't promote any of them to `stable` or `latest` last week. * NEW: We now install some plugins just when you need them, rather than include them automatically in a Salesforce CLI release. Let's use this week's new [plugin-sobject](https://github.com/salesforcecli/plugin-sobject) as an example. The plugin isn't included in `sfdx` by default, although `sfdx` _knows_ about it. When you run one of the plugin's commands for the first time, such as `sfdx schema generate sobject`, Salesforce CLI installs the latest released version of the plugin and then runs the command. The installation happens automatically, although we display a little message so you know what's going on. From then on, run any of the commands contained in the plugin as usual. And when you next run `sfdx update`, if the just-in-time plugin has released a new version, then it's also updated. Just a little just-in-time magic! * NEW: We continue to [improve the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands. This week's release includes updated [plugin-auth](https://github.com/salesforcecli/plugin-auth). The existing `sfdx` commands and their flags still work the same as before. These are the new command names. For each command, you can still use colons instead of spaces, such as `org:login:web`. |Existing Command Name|New Command Name| |------------|-------------| |`auth:web:login`|`org login web`| |`auth:jwt:grant`|`org login jwt`| |`auth:logout`|`org logout`| |`auth:list`|`org list auth`| |`auth:accesstoken:store`|`org login access-token`| |`auth:device:login`|`org login device`| |`auth:sfdxurl:store`|`org login sfdx-url`| These are the new flag names for the new command names listed above. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--jwtkeyfile`|`--jwt-key-file`|`auth:jwt:grant`| |`--clientid`|`--client-id`|`auth:jwt:grant`, `auth:web:login`, `auth:device:login`| |`--setdefaultdevhubusername`|`--set-default-dev-hub`|All commands except `auth:logout`| |`--setalias`|`--alias`|`auth:jwt:grant`, `auth:web:login`, `auth:accesstoken:store`, `auth:device:login`, `auth:sfdxurl:store`| |`--username`|Same, but new short flag name is `-o`|`auth:jwt:grant`| |`--instanceurl`|`--instance-url`|`auth:jwt:grant`, `auth:web:login`, `auth:accesstoken:store`, `auth:device:login`| |`--setdefaultusername`|`--set-default`|`auth:jwt:grant`, `auth:web:login`, `auth:accesstoken:store`, `auth:device:login`, `auth:sfdxurl:store`| |`--targetusername`|`--target-org`, with new short flag name `-o`|`auth:logout`| |`--noprompt`|`--no-prompt`|`auth:logout`, `auth:accesstoken:store`| |`--sfdxurlfile`|`--sfdx-url-file`|`auth:sfdxurl:store`| |`--apiversion`|Removed|`auth:logout`| This flag is deprecated and has no effect. |Deprecated Flag|Affected Existing Command| |---|---| |`--loglevel`|All commands| We also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. Let's look at an example, such as this command: ```bash sfdx auth:jwt:grant --username jdoe@example.org --jwtkeyfile /Users/jdoe/JWT/server.key --clientid 123456 --setdefaultdevhubusername ``` You can now run it this way using the `sf` style: ```bash sfdx org login jwt --username jdoe@example.org --jwt-key-file /Users/jdoe/JWT/server.key --client-id 123456 --set-default-dev-hub ``` Finally, just in case we weren't clear, the existing commands work exactly as before! But give this new stuff a try, we think you'll like it. * NEW: Interactively create local Salesforce metadata, such as custom objects and platform events, with these new beta commands in the just-in-time [plugin-sobject](https://github.com/salesforcecli/plugin-sobject) plugin: ```bash sfdx schema generate sobject sfdx schema generate platformevent sfdx schema generate field ``` The plugin isn't automatically included in Salesforce CLI; instead, it's automatically installed the first time you run one of its commands. Each command requires the `--label` flag, and then uses the value to provide intelligent suggestions for its prompts, such as its API name. You must run these commands in a Salesforce DX project directory. This example shows how to interactively create a custom object: ```bash sfdx schema generate sobject --label "My Fab Object" ``` Want to automatically enable optional features on the new custom object rather than answer all the prompts? Try this: ```bash sfdx schema generate sobject --label "My Fab Object" --use-default-features ``` Now create a custom field on your shiny new object; the command prompts you for the object: ```bash sfdx schema generate field --label "My Field" ``` Also, while not an interactive commands, you can also create a custom tab for a custom object with the new `sfdx schema generate tab` beta command. You must provide the object's API name, [icon number](https://www.lightningdesignsystem.com/icons/#custom), and local directory to store the files. For example: ```bash sfdx schema generate tab --object MyFabObject__c --icon 54 --directory force-app/main/default/tabs ``` Remember to run `sfdx force:source:deploy` to deploy the new local source files to your org. Then you can further customize the new components using Setup UI, then `sfdx force:source:retrieve` the changes back to your local project. * NEW: Use Bulk API 2.0 to upsert and delete data to and from your org with these new commands: * `sfdx data delete bulk` : Bulk delete records from an org using a CSV file. Uses Bulk API 2.0. * `sfdx data delete resume` : Resume a bulk delete job that you previously started. Uses Bulk API 2.0. * `sfdx data upsert bulk` : Bulk upsert records to an org from a CSV file. Uses Bulk API 2.0. * `sfdx data upsert resume` : Resume a bulk upsert job that you previously started. Uses Bulk API 2.0. For example, bulk upsert records from a CSV file to the Contact object in your default org with this command: ```bash sfdx data upsert bulk --sobject Contact --file files/contacts.csv --external-id Id ``` The preceding command returns control to you immediately and runs the bulk upsert asynchronously. Resume the job to see the results with this command: ```bash $ sfdx data upsert resume --use-most-recent ``` We recommend that you start using these new Bulk API 2.0 commands rather than the existing `sf force data bulk` commands, which are based on Bulk API 1.0. However, one reason to keep using the existing `sf force data bulk upsert` command is if you want to run the upsert serially with the `--serial` flag. The new Bulk API 2.0 commands don't support serial execution. In this case, or if you simply want to continue using Bulk API 1.0, use these commands: * `sfdx force data bulk delete` * `sfdx force data bulk upsert` * `sfdx force data bulk status` Run the commands with `--help` to see examples. Finally, the `sfdx data resume` command is deprecated. Use `sfdx data delete resume` or `sfdx data upsert resume` instead. * NEW: Generate your own custom `sf`-style plugins, commands, flags, and more with the commands in the just-in-time [plugin-dev](https://github.com/salesforcecli/plugin-dev). If you haven't already installed this plugin, simply type one of its commands and Salesforce CLI automatically installs it for you. For example, run this command to interactively generate the initial files and directory hierarchy for a new custom plugin; the command prompts you for the required information: ```bash sfdx dev generate plugin ``` **Important**: The new interactive `sfdx dev generate plugin` command _replaces_ the existing `sfdx plugins generate` command. The existing command generates `sfdx`-style plugins that are based on deprecated code, which we don't want you to use anymore. See [Get Started and Create Your Own Plugin](https://github.com/salesforcecli/cli/wiki/Get-Started-And-Create-Your-First-Plug-In) for simple examples of using the new commands. See [Generate Stuff](https://github.com/salesforcecli/cli/wiki/Code-Your-Plugin#generate-stu) for the full list. * NEW: When you type a command fragment and `sfdx` displays a list of possible commands for you to choose from, we now also display the command summary. The summaries make it easier for you to pick the command you want. * NEW: We continue to [improve the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands. This week's release includes updated [plugin-apex](https://github.com/salesforcecli/plugin-apex). The `sfdx` commands and their flags still work the same as before. These are the new command names. For each command, you can still use colons instead of spaces, such as `apex:run`. |Existing Command Name|New Command Name| |------------|-------------| |`force:apex:execute`|`apex run`| |`force:apex:log:get`|`apex get log`| |`force:apex:log:list`|`apex list log`| |`force:apex:log:tail`|`apex tail log`| |`force:apex:test:report`|`apex get test`| |`force:apex:test:run`|`apex run test`| These are the new flag names for the new command names listed above. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All commands| |`--targetusername`|`--target-org`, with new short name `-o`|All commands| |`--outputdir`|`--output-dir`|`force:apex:log:get`, `force:apex:test:report`, `force:apex:test:run`| |`--logid`|`--log-id`|`force:apex:log:get`| |`--codecoverage`|`--code-coverage`|`force:apex:test:run`, `force:apex:test:report`| |`--testrunid`|`--test-run-id`|`force:apex:test:report`| |`--resultformat`|`--result-format`|`force:apex:test:report`, `force:apex:test:run`| |`--apexcodefile`|`--file`|`force:apex:execute`| |`--testlevel`|`--test-level`|`force:apex:execute`| |`--classnames`|`--class-names`|`force:apex:execute`| |`--suitenames`|`--suite-names`|`force:apex:execute`| |`--detailedcoverage`|`--detailed-coverage`|`force:apex:execute`| |`--debuglevel`|`--debug-level`|`force:apex:log:tail`| |`--skiptraceflag`|`--skip-trace-flag`|`force:apex:log:tail`| This flag is deprecated and has no effect. |Deprecated Flag|Affected Existing Command| |---|---| |`--loglevel`|All commands| We also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. Let's look at an example, such as this command: ```bash sfdx force:apex:test:run --suitenames "MySuite,MyOtherSuite" --codecoverage --detailedcoverage --targetusename my-scratch --outputdir tests/output" ``` You can now run it this way using the `sf` style: ```bash sfdx apex run test --suite-names "MySuite,MyOtherSuite" --code-coverage --detailed-coverage --target-org my-scratch --output-dir tests/output" ``` * NEW: Configure autocomplete on Zsh for commands that use spaces as separators by running this command: ```bash sfdx autocomplete ``` Follow the displayed instructions to set up autocomplete in your environment. Then use the tab key to autocomplete commands. For example, if you type `sf data ` then press TAB, you'll get a list of data commands to chose from. You can also autocomplete flags: * Type `-` to see suggestions that show both the long and short flag names. For example, if you type `sf data query -` then press TAB, zsh displays all the flags for this command, including both short and long names. If you type `sf data query --`, then only the long names are shown. * For flags that define a set of valid values, type `--` to see the list. For example, if you type `sf data query --result-format` then press TAB, zsh suggests the valid options for this flag, which are `human`, `json`, or `csv`. * Flags that can be specified multiple times are still suggested, even if you've already used it. If you currently use autocomplete for colon-separated commands, you must regenerate the autocomplete cache to get this new behavior; nothing in your environment changes otherwise: ```bash sfdx autocomplete --refresh-cache ``` If you regenerate the cache, but then want to go back to autocompleting commands that use `:` as a separator, first set this environment variable: ```bash OCLIF_AUTOCOMPLETE_TOPIC_SEPARATOR=colon ``` Then regenerate the autocomplete cache again (`sfdx autocomplete --refresh-cache`). * NEW: The `sfdx org display` (`force:org:display`) output now includes the API version of the org at the time you authorized it with the `sfdx auth:*` commands. We cache the value locally, so if Salesforce updates your org to a new release, the API version will be incorrect. Re-login to your org to refresh the API version information in the `sfdx org display` output. (GitHub issue [#314](https://github.com/forcedotcom/cli/issues/314), plugin-org PR [#580](https://github.com/salesforcecli/plugin-org/pull/580)) * CHANGE: Michelangelo created David, NASA put an astronaut on the moon, and Beyoncé just won her 32nd GRAMMY. Not to be outdone, the Salesforce CLI team delivered an equally impressive accomplishment this week: a 100% [open-source CLI](https://developer.salesforce.com/blogs/2023/02/achieving-an-open-source-salesforce-cli). After methodically breaking up the original `salesforce-alm` plugin into smaller open-source plugins, we finally removed it completely from Salesforce CLI this week. It was the last remaining private plugin. The only noticeable change is that commands with `legacy` in their name are no longer available. But don't worry, if you want them back, you can always reinstall the plugin like this: ```bash sfdx plugins install salesforce-alm ``` Alternatively, install a version of Salesforce CLI that still contains the `salesforce-alm` plugin, such as `7.188.1`: ```bash sfdx update --version 7.188.1 ``` Congratulations, team, on achieving a significant goal that's been a long-time coming! * CHANGE: If you run `force:apex:execute` and the compilation or execution of the anonymous Apex code fails, you now get a non-zero exit code, which is more intuitive. Previously the command execution was still considered a success (zero exit code). NOTE that this is a breaking change. After we [announced it](https://github.com/forcedotcom/cli/issues/1889), we got lots of positive feedback, so we made the change. Thanks for your input. Thank you, [Matthias Rolke](https://github.com/amtrack), for contributing the fix. We love it. Keep 'em coming! * FIX: You can now specify `packageAliases` that contain spaces in the `sfdx-project.json` file and execute `package` commands that use the alias without getting an error. (GitHub issue [#1936](https://github.com/forcedotcom/cli/issues/1936), oclif PR [#614](https://github.com/oclif/core/pull/614)) * FIX: For backwards compatibility, we added the `-v|--targetdevhubusername` flag back to the `force org delete` and `org delete scratch` commands, even though the flag doesn't do anything and is deprecated. (GitHub issue [#1925](https://github.com/forcedotcom/cli/issues/1925), plugin-org PR [#581](https://github.com/salesforcecli/plugin-org/pull/581)) * FIX: When the `sfdx org create scratch` command deploys the org settings, it waits for the amount of time left from the specified `--wait` value. Previously it waited for a maximum of 10 minutes for this step, regardless of the value of `--wait`. (GitHub issue [#1817](https://github.com/forcedotcom/cli/issues/1817), sfdx-core PR [#771](https://github.com/forcedotcom/sfdx-core/pull/771)) * FIX: If you run into authentication errors when running `sfdx org list shape` (`force:org:shape:list`), such as an expired refresh token, the displayed table now shows information for orgs the command can connect to, and an appropriate warning for orgs it can't connect to. (GitHub issue [#1882](https://github.com/forcedotcom/cli/issues/1882), plugin-signups PR [#216](https://github.com/salesforcecli/plugin-signups/pull/216)) * FIX: The `--publishwait` flag of `force:package:install` correctly waits for the specified amount of time for the subscriber package version ID to become available in the target org. And this time we mean it! (GitHub issue [#1895](https://github.com/forcedotcom/cli/issues/1895), plugin-packaging PR [#235](https://github.com/salesforcecli/plugin-packaging/pull/235)) * FIX: Commands are no longer duplicated in the output of `sfdx commands --json`. (GitHub issue [#1777](https://github.com/forcedotcom/cli/issues/1777), plugin-commands PR [#382](https://github.com/oclif/plugin-commands/pull/382)) * FIX: Packaging commands support aliases with spaces in them. (GitHub issue [#1936](https://github.com/forcedotcom/cli/issues/1936), oclif-core PR [#614](https://github.com/oclif/core/pull/614)) ## 7.188.1 (Feb 16, 2023) * NEW: We continue to [improve the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands. This week's release includes updated [plugin-templates](https://github.com/salesforcecli/plugin-templates). The `sfdx` commands and their flags still work the same as before. These are the new command names. For each command, you can still use colons instead of spaces, such as `analytics:generate:template`. |Existing Command Name|New Command Name| |------------|-------------| |`force:analytics:template:create`|`analytics generate template`| |`force:apex:class:create`|`apex generate class`| |`force:apex:trigger:create`|`apex generate trigger`| |`force:lightning:app:create`|`lightning generate app`| |`force:lightning:component:create`|`lightning generate component`| |`force:lightning:event:create`|`lightning generate event`| |`force:lightning:interface:create`|`lightning generate interface`| |`force:lightning:test:create`|`lightning generate test`| |`force:project:create`|`project generate`| |`force:staticresource:create`|`static-resource generate`| |`force:visualforce:component:create`|`visualforce generate component`| |`force:visualforce:page:create`|`visualforce generate page`| These are the new flag names for the new command names listed above. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All commands| |`--outputdir`|`--output-dir`|All commands| |`--XXname`, such as `--classname` of `force:apex:class:create` or `--appname` of `force:lightning:app:create`|`--name`|All commands.| |`--triggerevents`|`--event`|`force:apex:trigger:create`| |`--defaultpackagedir`|`--default-package-dir`|`force:project:create`| This flag is deprecated and has no effect. |Deprecated Flag|Affected Existing Command| |---|---| |`--loglevel`|All commands| We also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. Let's look at an example, such as this command: ```bash sfdx force:apex:trigger:create --triggername MyTrigger --sobject Account --triggerevents "before insert,after insert" ``` You can now run it this way using the `sf` style: ```bash sfdx apex generate trigger --name MyTrigger --sobject Account --event "before insert" --event "after insert" ``` Note that we split up the values to `--event`, which is the `sf` way of passing multiple values to a flag. You could also do it this way: ```bash sfdx apex generate trigger --name MyTrigger --sobject Account --event "before insert" "after insert" ``` Finally, just in case we weren't clear, the existing commands work exactly as before! But give this new stuff a try, it's pretty cool. * NEW: We now provide the `arm64` flavor of the `.pkg` and TAR files for installing Salesforce CLI on macOS. The new files include a version of Node.js that's built for Apple Silicon CPUs. If your computer uses an Apple Silicon CPU, you'll likely get a small performance boost if you [uninstall your current version of Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_uninstall.htm) and then [reinstall](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli_macos) using the [.pkg installer](https://developer.salesforce.com/tools/sfdxcli#) or [TAR file](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli_linux) labeled "Apple Silicon" (GitHub issue [#1045](https://github.com/forcedotcom/cli/issues/1045) and [#768](https://github.com/forcedotcom/cli/issues/768)). * CHANGE: We upgraded the version of Node.js contained in the [Salesforce CLI installers, TAR files, and Docker images](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm) to [v18.14.0](https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V18.md#2023-02-02-version-18140-hydrogen-lts-bethgriggs-prepared-by-juanarbol). * CHANGE: Do you develop custom Salesforce CLI plugins? If so, this note is for you. We marked `SfdxCommand` (the base class for `sfdx` plugins) and other code in [this repo](https://github.com/salesforcecli/command) as deprecated. We plan to continue updating dependencies in the repo for a while longer, but we recommend you start looking at [this repo](https://github.com/salesforcecli/sf-plugins-core) for all your plugin command needs, such as `SfCommand`. Check out [Migrate Plugins Build for sfdx](https://github.com/salesforcecli/cli/wiki/Migrate-Plugins-Built-For-Sfdx) for details. * FIX: The `data query` command no longer suppresess or nullifies the value of `0` (in human-readable output) when it's returned by a SOQL query. (GitHub issue [#1892](https://github.com/forcedotcom/cli/issues/1892), plugin-data PR [#470](https://github.com/salesforcecli/plugin-data/pull/470)) Many thanks to [Leo Stewart](https://github.com/leostewart) for reporting the issue, and then providing the fix. We're stoked with your contribution, and we look forward to more from you and community! * FIX: The `package version list` command now supports multiple packages specified as comma-delimited entries. (GitHub issue [#1912](https://github.com/forcedotcom/cli/issues/1912), plugin-packaging PR [#249](https://github.com/salesforcecli/plugin-packaging/pull/249)) * FIX: The `package version create` command runs successfully even if your `sfdx-project.json` file doesn't contain a `versionName` option for defining the package. (GitHub issue [#1907](https://github.com/forcedotcom/cli/issues/1907), packaging PR [#219](https://github.com/forcedotcom/packaging/pull/219)) * FIX: When using `force source retrieve` to retrieve bundle metadata types, such as LightningComponentBundle, the files and directories listed in the `.forceignore` file are correctly ignored. (GitHub issue [#1904](https://github.com/forcedotcom/cli/issues/1904), SDR PR [#847](https://github.com/forcedotcom/source-deploy-retrieve/pull/847)) * FIX: The `force source` commands now support the ExperiencePropertyTypeBundle metadata type. * FIX: Commands that have transitioned to the new `sf` style now emit their warnings to stderr instead of stdout. (GitHub issue [#1926](https://github.com/forcedotcom/cli/issues/1926), sf-plugins-core PR [#216](https://github.com/salesforcecli/sf-plugins-core/pull/216)). ## 7.187.1 (Feb 9, 2023) * NEW: We continue to [improve the usability](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) of existing `sfdx` commands. This week's release includes updated [plugin-org](https://github.com/salesforcecli/plugin-org). The existing `sfdx` commands and their flags still work the same as before, although we've deprecated some commands and flags and added new ones. Here's a summary. These are the new command names. For each command, you can still use colons instead of spaces, such as `org:open`. |Existing Command Name|New Command Name| |-----------------------|---------| |`force:org:open`|`org open`| |`force:org:list`|`org list`| |`force:org:display`|`org display`| These are the deprecated commands, along with the new commands you should use instead. For each command, you can still use colons instead of spaces, such as `org:create:sandbox`. |Deprecated command|Use this command instead| |-----------------------|---------| |`force:org:create`|`org create sandbox` or `org create scratch`| |`force:org:delete`|`org delete sandbox` or `org delete scratch`| |`force:org:status`|`org resume sandbox`| |`force:org:clone`|`org create sandbox`| These are the new flag names for the `force:org:*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All commands| |`--clientid`|`--client-id`|`force:org:create`| |`--definitionfile`|`--definition-file`|`force:org:create`, `force:org:clone`| |`--durationdays`|`--duration-days`, with new short name `-y`|`force:org:create`| |`--noancestors`|`--no-ancestors`|`force:org:create`| |`--nonamespace`|`--no-namespace`, with new short name `-m`|`force:org:create`| |`--noprompt`|`--no-prompt`|All commands| |`--setalias`|`--alias`|`force:org:create`, `force:org:clone`| |`--setdefaultusername`|`--set-default`, with new short name `-d`|`force:org:clone`, `force:org:create`, `force:org:status`| |`--skipconnectionstatus`|`--skip-connection-status`|`force:org:list`| |`--targetdevhubusername`|`--target-dev-hub`|All commands| |`--targetusername`|`--target-org`, with new short name `-o`|All commands| |`--urlonly`|`--url-only`|`force:org:open`| These flags are deprecated and have no effect. |Deprecated Flag|Affected Existing Command| |---|---| |`--loglevel`|All commands| We also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Fun tip: use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. The new commands to manage sandboxes and scratch orgs work a bit differently from the `force:org:*` commands. For example, we split `force:org:create` into two commands, one each for scratch orgs and sandboxes, which is more intuitive. We also introduced commands to resume org creation, which is particularly useful when a scratch org creation times out. Previously you could no longer connect to it and you had to manually delete it from your Dev Hub. Now you can easily resume where it left off using a job ID. When the creation finishes, the command automatically authenticates to the org, saves the org info locally, and deploys any configured settings. Let's look at a few examples to get you started with these new commands. This existing way to create a scratch org: ```bash sfdx force:org:create --definitionfile config/enterprise-scratch-def.json --setalias MyScratchOrg --targetdevhubusername MyDevHub --nonamespace --setdefaultusername ``` Looks like this in the `sf` style: ```bash sfdx org create scratch --definition-file config/enterprise-scratch-def.json --alias MyScratchOrg --target-dev-hub MyDevHub --no-namespace --set-default ``` This command to create a sandbox: ```bash sfdx force:org:create --type sandbox --definitionfile config/dev-sandbox-def.json --setalias MyDevSandbox --targetusername ProdOrg ``` Now looks like this in the `sf` style: ```bash sfdx org create sandbox --definition-file config/dev-sandbox-def.json --alias MyDevSandbox --target-org ProdOrg ``` This command to delete a scratch org: ```bash sfdx force:org:delete --targetusername MyDevSandbox --noprompt ``` Looks like this in the `sf` style: ```bash sfdx org delete sandbox --target-org MyDevSandbox --no-prompt ``` Here's an example of resuming a timed-out scratch org creation. Let's say you run this command: ```bash sfdx org create scratch --definition-file config/enterprise-scratch-def.json --wait 3 --alias MyScratchOrg --target-dev-hub MyDevHub ``` If the scratch org creation doesn't complete in 3 minutes, Salesforce CLI returns control of the terminal to you and displays a job ID. Pass the ID to the `sfdx org resume scratch` command to resume the job: ```bash sfdx org resume scratch --job-id 2SR3u0000008fBDGAY ``` Alternatively, use the handy `--use-most-recent` flag to, yep, resume the most recent scratch org create job: ```bash sfdx org resume scratch --use-most-recent ``` Cool beans, no? Enjoy! * NEW: Use the new `--verbose` flag of `force:package:version:create` to display a new line of status and timeout data for each poll request. By default, the command displays a spinner with a message that updates on every poll request. This new flag is useful in CI systems to prevent timeouts that can occur during long periods of no output from commands. (GitHub issue [#1894](https://github.com/forcedotcom/cli/issues/1894), plugin-packaging PR [#236](https://github.com/salesforcecli/plugin-packaging/pull/236)) * FIX: The `force:source:retrieve` command, run with either the `--metadata` or `--sourcepath` flag, correctly ignores the `_tests_` directory if it's listed in the `.forceignore` file. (GitHub issue [#1904](https://github.com/forcedotcom/cli/issues/1904)) * FIX: The `--publishwait` flag of `force:package:install` correctly waits for the specified amount of time for the subscriber package version ID to become available in the target org. (GitHub issue [#1895](https://github.com/forcedotcom/cli/issues/1895), plugin-packaging PR [#235](https://github.com/salesforcecli/plugin-packaging/pull/235)) * FIX: The `force:source:*` commands now support these metadata types: * AccountingFieldMapping * AccountingModelConfig * ActionLauncherItemDef * ActionableListDefinition * ExplainabilityMsgTemplate * IntegrationProviderDef * LocationUse * PersonAccountOwnerPowerUser * PipelineInspMetricConfig * ProductSpecificationTypeDefinition ## 7.186.2 (Feb 2, 2023) * NEW: We continue to improve the usability of existing `sfdx` commands, such as more intuitive flag names and using spaces as separators, similar to how `sf` works. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. We're doing this work plugin by plugin. This week's release includes updated [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) and [plugin-user](https://github.com/salesforcecli/plugin-user). Don't worry, the `sfdx` commands and their flags still work the same as before! But give the new style a try -- we think you'll like it. These are the new command names. For each command, you can still use colons instead of spaces, such as `org:create:user`. |Existing Command Name|New Command Name| |-----------------------|---------| |`force:user:create`|`org create user`| |`force:user:display`|`org display user`| |`force:user:list`|`org list users`| |`force:user:password:generate`|`org generate password`| |`force:user:permset:assign`|`org assign permset`| |`force:user:permsetlicense:assign`|`org assign permsetlicense`| |`force:package1:version:create`|`package1 version create`| |`force:package1:version:create:get`|`package1 version create get`| |`force:package1:version:display`|`package1 version display`| |`force:package1:version:list`|`package1 version list`| |`force:package:create`|`package create`| |`force:package:delete`|`package delete`| |`force:package:install`|`package install`| |`force:package:install:report`|`package install report`| |`force:package:installed:list`|`package installed list`| |`force:package:list`|`package list`| |`force:package:uninstall`|`package uninstall`| |`force:package:uninstall:report`|`package uninstall report`| |`force:package:update`|`package update`| |`force:package:version:create`|`package version create`| |`force:package:version:create:list`|`package version create list`| |`force:package:version:create:report`|`package version create report`| |`force:package:version:delete`|`package version delete`| |`force:package:version:displayancestry`|`package version displayancestry`| |`force:package:version:list`|`package version list`| |`force:package:version:promote`|`package version promote`| |`force:package:version:report`|`package version report`| |`force:package:version:update`|`package version update`| These are the new flag names for the `force:package1:*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All `force:package1:*` commands| |`--installationkey`|`--installation-key` | `force:package1:version:create`| |`--managedrelease`|`--managed-release` | `force:package1:version:create`| |`--packageid`|`--package-id` | `force:package1:version:create`, `force:package1:version:list`| |`--packageversionid`|`--package-version-id` | `force:package1:version:display`| |`--postinstallurl`|`--post-install-url` | `force:package1:version:create`| |`--releasenotesurl`|`--release-notes-url` | `force:package1:version:create`| |`--requestid`|`--request-id` | `force:package1:version:create:get`| |`--targetusername`|`--target-org`, with new short name `-o` | `force:package1:version:create`, `force:package1:create:get`, `force:package1:display`, `force:package1:list`| These are the new flag names for the `force:package:*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apexcompile`|`--apex-compile`|`force:package:install`| |`--codecoverage`|`--code-coverage`|`force:package:version:create`| |`--createdlastdays`|`--created-last-days`|`force:package:version:create:list`, `force:package:version:list`| |`--definitionfile`|`--definition-file`|`force:package:version:create`| |`--dotcode`|`--dot-code`|`force:package:version:displayancestry`| |`--errornotificationusername`|`--error-notification-username`|`force:package:create`, `force:package:update`| |`--installationkey`|`--installation-key`|`force:package:install`, `force:package:version:create`, `force:package:version:update`| |`--installationkeybypass`|`--installation-key-bypass`|`force:package:version:create`| |`--modifiedlastdays`|`--modified-last-days`|`force:package:version:list`| |`--nonamespace`|`--no-namespace`|`force:package:create`| |`--noprompt`|`--no-prompt`|`force:package:delete`, `force:package:install`, `force:package:version:delete`, `force:package:version:promote`| |`--orderby`|`--order-by`|`force:package:version:list`| |`--orgdependent`|`--org-dependent`|`force:package:create`| |`--packagecreaterequestid`|`--package-create-request-id`|`force:package:version:create:report`| |`--packagetype`|`--package-type`|`force:package:create`| |`--postinstallscript`|`--post-install-script`|`force:package:version:create`| |`--postinstallurl`|`--post-install-url`|`force:package:version:create`| |`--publishwait`|`--publish-wait`|`force:package:install`| |`--releasenotesurl`|`--releasenotes-url`|`force:package:version:create`| |`--requestid`|`--request-id`|`force:package:install:report`, `force:package:uninstall:report`| |`--securitytype`|`--security-type`|`force:package:install`| |`--skipancestorcheck`|`--skip-ancestor-check`|`force:package:version:create`| |`--skipvalidation`|`--skip-validation`|`force:package:version:create`| |`--targetdevhubusername`|`--target-hub-org`|`force:package:create`, `force:package:delete`, `force:package:list`, `force:package:update`, `force:package:version:create`, `force:package:version:create:list`, `force:package:version:create:report`, `force:package:version:delete`, `force:package:version:displayancestry`, `force:package:version:list`, `force:package:version:promote`, `force:package:version:report`, `force:package:version:update`| |`--targetusername`|`--target-org`, with new short name `-o` | `force:package:install`, `force:package:install:report`, `force:package:installed:list`, `force:package:uninstall`, `force:package:uninstall:report`| |`--uninstallscript`|`--uninstall-script`|`force:package:version:create`| |`--upgradetype`|`--upgrade-type`|`force:package:install`| |`--versiondescription`|`--version-description`|`force:package:version:create`, `force:package:version:update`| |`--versionname`|`--version-name`|`force:package:version:create`, `force:package:version:update`| |`--versionnumber`|`--version-number`|`force:package:version:create`| These are the new flag names for the `force:user:*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All `force:user:*` commands| |`--targetusername`|`--target-org`, with new short name `-o` | `force:user:permset:generate`, `force:user:permsetlicense:generate`, `force:user:create`, `force:user:display`, `force:user:password:generate`, `force:user:list`| |`--onbehalfof`|`--on-behalf-of` , with new short name `-b`| `force:user:permset:generate`, `force:user:permsetlicense:generate`, `force:user:password:generate`| |`--permsetname`|`--name` | `force:user:permset:generate`| |`--setalias`|`--set-alias` | `force:user:create`| |`--definitionfile`|`--definition-file` | `force:user:create`| |`--setuniqueusername`|`--set-unique-username` | `force:user:create`| These flags are deprecated and have no effect. |Existing Command|Deprecated Flags| |---|---| |All commands|`--loglevel`| |All `force:user:*` commands| `--targetdevhubusername`| We also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Fun tip: use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. Let's look at an example, such as this command (IDs truncated for security): ```bash sfdx force:package:version:create --package "Your Package Alias" --installationkey password123 --skipvalidation --targetdevhubusername devhub@example.com ``` You can now run it this way using the `sf` style: ```bash sfdx package version create --package "Your Package Alias" --installation-key password123 --skip-validation --target-hub-org devhub@example.com ``` Finally, just in case we weren't clear, the existing commands work exactly as before! But give this new stuff a try, it's pretty cool. * CHANGE: Remember how we [updated the `force:cmdt` commands](./README.md#71842-jan-19-2023) to be in the style of `sf`? We changed their official new names: | Existing Command Name | New Command Name| |---|---| |`generate cmdt object`|`cmdt generate object`| |`generate cmdt field `|`cmdt generate field `| |`generate cmdt fromorg`|`cmdt generate fromorg`| |`generate cmdt record`|`cmdt generate record`| |`generate cmdt records`|`cmdt generate records`| * FIX: When running `force:org:delete` to delete a scratch or sandbox org, all local source tracking files associated with the deleted org are cleaned up correctly. (GitHub issue [#1879](https://github.com/forcedotcom/cli/issues/1879), sfdx-core PR [#754](https://github.com/forcedotcom/sfdx-core/pull/754)) * FIX: When deploying multiple package directories sequentially (by including `"pushPackageDirectoriesSequentially" : true` in your `sfdx-project.json` file), the deploy command no longer displays duplicate log entries. (GitHub issue [#1879](https://github.com/forcedotcom/cli/issues/1879), SDR PR [#825}(https://github.com/forcedotcom/source-deploy-retrieve/pull/825), plugin-source PR [#698](https://github.com/salesforcecli/plugin-source/pull/698)) * FIX: The `force:source:manifest:generate --fromorg` command now correctly includes the StandardValueSets metadata type if it's present in your org. (GitHub issue [#1877](https://github.com/forcedotcom/cli/issues/1877), SDR PR [#824](https://github.com/forcedotcom/source-deploy-retrieve/pull/824)) * FIX: The `force:cmdt:record:create` command is now working correctly and no longer returns `Error: Unexpected arguments`. (GitHub issue [#1893](https://github.com/forcedotcom/cli/issues/1893), plugin-custom-metadata PR [#380](https://github.com/salesforcecli/plugin-custom-metadata/pull/380)) ## 7.185.0 (Jan 26, 2023) * NEW: We continue to improve the usability of existing `sfdx` commands, such as more intuitive flag names and using spaces as separators, similar to how `sf` works. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. We're doing this work plugin by plugin. This week's release includes updated [plugin-signups](https://github.com/salesforcecli/plugin-signups). Don't worry, the `sfdx` commands and their flags still work _exactly_ the same as before! But give the new style a try -- we think you'll like it. These are the new command names. For each command, you can still use colons instead of spaces, such as `org:create:shape`. |Existing Command Name|New Command Name| |-----------------------|---------| |`force:org:shape:create`|`org create shape`| |`force:org:shape:delete`|`org delete shape`| |`force:org:shape:list`|`org list shape`| |`force:org:snapshot:create` (Pilot)|`org create snapshot` (Pilot)| |`force:org:snapshot:delete` (Pilot)|`org delete snapshot` (Pilot)| |`force:org:snapshot:get` (Pilot)|`org get snapshot` (Pilot)| |`force:org:snapshot:list` (Pilot)|`org list snapshot` (Pilot)| These are the new flag names for the `force:org:shape::*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All `force:org:shape:*` commands| |`--targetusername`|`--target-org`, with new short name `-o`|`force:org:shape:create`, `force:org:shape:delete`| |`--noprompt`|`--no-prompt`|`force:org:shape:delete`| These are the new flag names for the `force:org:snapshot:*` pilot commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All `force:org:snapshot:*` commands| |`--targetdevhubusername`|`--target-dev-hub`|All `force:org:snapshot:*` commands| |`--snapshotname`|`--name`|`force:org:snapshot:create`| |`--sourceorg`|`--source-org`|`force:org:snapshot:create`| These flags are deprecated and have no effect. |Existing Command|Deprecated Flags| |---|---| |All commands|`--loglevel`| |`force:org:shape:list`|`--verbose`| We also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Fun tip: use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. Let's look at an example, such as this command: ```bash sfdx force:org:snapshot:create --sourceorg myuser@myorg.com --snapshotname NightlyBranch --description 'Contains PkgA v2.1.0' --targetdevhubusername NightlyDevHub ``` You can now run it this way using the `sf` style: ```bash sfdx org create snapshot --source-org myuser@myorg.com --name NightlyBranch --description 'Contains PkgA v2.1.0' --target-dev-hub NightlyDevHub ``` We've said this a lot, but here it is again: the existing commands work exactly as before. But give this new stuff a try, you might like it. * FIX: You can now correctly execute `force:package:version:create` when the org definition file specified by the `--definitionfile` flag uses the `language` option to specify a default language. (plugin-packaging PR [#218](https://github.com/salesforcecli/plugin-packaging/pull/218)) ## 7.184.2 (Jan 19, 2023) * NEW: We continue to improve the usability of existing `sfdx` commands, such as more intuitive flag names and using spaces as separators, similar to how `sf` works. See [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) for details. We're doing this work plugin by plugin. This week's release includes updated [plugin-data](https://github.com/salesforcecli/plugin-data), [plugin-community](https://github.com/salesforcecli/plugin-community), and [plugin-custom-metadata](https://github.com/salesforcecli/plugin-custom-metadata). Don't worry, the `sfdx` commands and their flags still work _exactly_ the same as before! But give the new style a try -- we think you'll like it. These are the new command names. For each command, you can still use colons instead of spaces, such as `community:create`. |Existing Command Name|New Command Name| |-----------------------|---------| |`force:community:create`|`community create`| |`force:community:publish`|`community publish`| |`force:community:template:list`|`community list template`| |`force:data:bulk:delete`|`data delete bulk`| |`force:data:bulk:status`|`data resume`| |`force:data:bulk:upsert`|`data upsert bulk`| |`force:data:record:create`|`data create record`| |`force:data:record:delete`|`data delete record`| |`force:data:record:get`|`data get record`| |`force:data:record:update`|`data update record`| |`force:data:soql:bulk:report`|`data query resume`| |`force:data:soql:query`|`data query`| |`force:data:tree:export`|`data export tree`| |`force:data:tree:import`|`data import tree`| |`force:cmdt:create`|`generate cmdt object`| |`force:cmdt:field:create`|`generate cmdt field`| |`force:cmdt:generate`|`generate cmdt fromorg`| |`force:cmdt:record:create`|`generate cmdt record`| |`force:cmdt:record:insert`|`generate cmdt records`| These are the new flag names for the `force:community:*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |`--apiversion`|`--api-version`|All `force:community:*` commands| |`--templatename`|`--template-name`|`force:community:create`| |`--urlpathprefix`|`--url-path-prefix`|`force:community:create`| These are the new flag names (and one new flag!) for the `force:data:*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---|---|---| |(new flag)|`--async`|`force:data:soql:query`| |`--apiversion`|`--api-version`|All `force:data:*` commands| |`--sobjectype`|`--sobject`|`force:data:record:create`, `force:data:bulk:delete`, `force:data:record:delete`, `force:data:record:get`, `force:data:record:update`, `force:data:bulk:upsert`| |`--usetoolingapi`|`--use-tooling-api`|`force:data:record:create`, `force:data:record:delete`, `force:data:record:get`, `force:data:record:update`, `force:data:soql:query`| |`--csvfile`|`--file`|`force:data:bulk:delete`, `force:data:bulk:upsert`| |`--sobjectid`|`--record-id`|`force:data:record:delete`, `force:data:record:get`, `force:data:record:update`| |`--outputdir`|`--output-dir`|`force:data:tree:export`| |`--sobjecttreefiles`|`--files`|`force:data:tree:import`| |`--confighelp`|`--config-help`|`force:data:tree:import`| |`--soqlqueryfile`|`--file`|`force:data:soql:query`| |`--resultformat`|`--result-format`|`force:data:soql:query`, `force:data:soql:bulk:report`| |`--bulkqueryid`|`--bulk-query-id`|`force:data:soql:bulk:report`| |`--batchid`|`--batch-id`|`force:data:bulk:status`| |`--jobid`|`--job-id`|`force:data:bulk:status`| |`--externalid`|`--external-id`|`force:data:bulk:upsert`| These are new flag names for the `force:cmdt:*` commands. If an existing flag name isn't listed in the table, it has the same name in the new command name. |Existing Flag Name|New Flag Name|Affected Existing Commands| |---------------|----------------------|-----------------------| |`--apiversion`|`--api-version`|All `force:cmdt:*` commands| |`--decimalplaces`|`--decimal-places`|`force:cmdt:field:create`| |`--devname`|`--dev-name`|`force:cmdt:generate`| |`--fieldname`|`--name`|`force:cmdt:field:create`| |`--fieldtype`|`--type`|`force:cmdt:field:create`| |`--filepath`|`--csv`|`force:cmdt:record:insert`| |`--ignoreunsupported`|`--ignore-unsupported`|`force:cmdt:generate`| |`--inputdir`|`--input-directory`|`force:cmdt:record:create`, `force:cmdt:record:insert`| |`--namecolumn`|`--name-column`|`force:cmdt:record:insert`| |`--outputdir`|`--output-directory`|`force:cmdt:field:create`, `force:cmdt:create`, `force:cmdt:record:create`, `force:cmdt:record:insert`| |`--picklistvalues`|`--picklist-values`|`force:cmdt:field:create`| |`--plurallabel`|`--plural-label`|`force:cmdt:generate`, `force:cmdt:create`| |`--recordname`|`--record-name`|`force:cmdt:record:create`| |`--recordsoutputdir`|`--records-output-dir`|`force:cmdt:generate`| |`--sobjectname`|`--sobject`|`force:cmdt:generate`| |`--typeoutputdir`|`--type-output-directory`|`force:cmdt:generate`| |`--typename`|`--type-name`|`force:cmdt:create`, `force:cmdt:record:create`, `force:cmdt:record:insert`| These flags are deprecated and have no effect. |Existing Command|Deprecated Flags| |---|---| |All commands|`--loglevel`| |`force:data:record:create`|`--perflog`| |`force:data:record:update`|`--perflog`| |`force:data:soql:bulk:report`|`--perflog`, `--wait`, `--bulk`, `--usetoolingapi`, `--soqlqueryfile`, `--query`| We also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Fun tip: use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. Let's look at an example, such as this command (IDs truncated for security): ```bash sfdx force:data:record:get --usetoolingapi --sobjecttype TraceFlag --sobjectid 7tf8H --targetusername MyScratch ``` You can now run it this way using the `sf` style: ```bash sfdx data get record --use-tooling-api --sobject TraceFlag --record-id 7tf8H --target-org MyScratch ``` Finally, just in case we weren't clear, the existing commands work exactly as before! But give this new stuff a try, it's pretty cool. * NEW: We reached an important milestone today: the entire Salesforce CLI (excluding the `legacy` commands) is open source. The final private plugin ([plugin-custom-metadata](https://github.com/salesforcecli/plugin-custom-metadata), which contains the `cmdt` commands) is now public. Congrats, team! * FIX: Plugins that are linked locally with the `sfdx plugins link` command now automatically compile when you make a local change to them. Previously you had to run `yarn build` each time you made a change. (GitHub issue [#1664](https://github.com/forcedotcom/cli/issues/1664), oclif PR [#517](https://github.com/oclif/plugin-plugins/pull/517)) ## 7.183.1 (Jan 12, 2023) ANNOUNCEMENT: Happy new year, Salesforce CLI community! Be sure to read our latest [blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli) that describes some of the big improvements that are coming in Salesforce CLI this year. And now back to our regular schedule. * NEW: After a [successful beta](https://github.com/forcedotcom/cli/issues/1721) and incorporating feedback from our community, the commands that used to be in the `force:package1:beta` and `force:package:beta` topics are now generally available. What does this mean? Let's look at an example: the functionality we added to `force:package:beta:create` is now in `force:package:create`. The functionality in the _old_ `force:package:create` is now in `force:package:legacy:create`. In the short term, you can use the `force:package1:legacy:*` and `force:package:legacy:*` commands if you run into issues with the new commands. The new commands are open-source, live in the [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) plugin, and are semantically (name, flags) and functionally equivalent as the old commands. * NEW: As described in [this blog post](https://developer.salesforce.com/blogs/2022/12/big-improvements-coming-to-the-salesforce-cli), we're updating many of the existing `sfdx` commands to use the improvements we made in `sf`. We're doing this work plugin by plugin, starting this week with the commands in [plugin-limits](https://github.com/salesforcecli/plugin-limits) and [plugin-schema](https://github.com/salesforcecli/plugin-schema). Don't worry, the `sfdx` commands and their flags still work _exactly_ the same as before! But you can now run them using the `sf` style, such as spaces instead of colons and new flag names; we highly recommend you give it a try. These are the new command names. |Existing Command Name|New Command Names| |-------------------------------------|---------| |`force:limits:api:display`|`limits:api:display` (or `limits api display`)| |`force:limits:recordcounts:display`|`limits:recordcounts:display` (or `limits recordcounts display`)| |`force:schema:sobject:describe`|`sobject:describe` (or `sobject describe`)| |`force:schema:sobject:list`|`sobject:list` (or `sobject list`)| And these are the new flag names. |Existing Command|Existing Flag Name|New Flag Name| |---------|------|---| |All four commands|`--apiversion`|`--api-version`| |All four commands|`--targetusername`|`--target-org` (new short name `-o`)| |`force:limits:recordcounts:display`|`--sobjecttype`|`--sobject` | |`force:schema:sobject:describe`|`--sobjecttype`|`--sobject`| |`force:schema:sobject:describe`|`--usetoolingapi`|`--use-tooling-api`| |`force:schema:sobject:list`|`--sobjecttype`|`--sobject`| For all four commands, the existing `--loglevel` flag is deprecated and has no effect. We've also updated the `--help` for each command to use the new command and flag names, to gently encourage you to start switching over to the new style. Fun tip: use the `-h` flag to get a condensed view of the help, for when you don't need long descriptions and examples. Let's look at an example, such as this command: ```bash sfdx force:schema:sobject:describe --sobjecttype ApexCodeCoverage --usetoolingapi --targetusername my-scratch-org ``` You can now run it this way, using the `sf` style: ```bash sfdx sobject describe --sobject ApexCodeCoverage --use-tooling-api --target-org my-scratch-org ``` Finally, just in case we weren't clear, the existing commands work exactly as before! But give this new stuff a try, it's pretty cool. * NEW: Don't remember the exact name of a command? We got you: simply type the command fragments that you do remember, in any order, and press return. Then `sfdx` either displays a list of possible commands that you can choose from, or it automatically runs the command if there's only one choice. You get a friendly warning for the latter, so you know exactly what the CLI is doing. You're welcome. * NEW: Change the source-tracked file batch size during a deploy or retrieve with the new `SFDX_SOURCE_TRACKING_BATCH_SIZE` environment variable. The default value for this env var is 8,000 (Windows) and 15,000 (Linux/macOS). `SFDX_SOURCE_TRACKING_BATCH_SIZE` is useful when deploying or retrieving a large project that contains many source-tracked files, and you exceed your operating system open file limit. While the deploy or retrieve likely complete successfully, source-tracking can run into errors in this case. Either increase your open file limit, such as with the `ulimit -Hn ` Linux/macOS command, or set the `SFDX_SOURCE_TRACKING_BATCH_SIZE` environment variable to a number significantly lower than the output of `ulimit -Hn`. This new feature fixes these GitHub issues: [#1711](https://github.com/forcedotcom/cli/issues/1711), [#1676](https://github.com/forcedotcom/cli/issues/1676), and [#1504](https://github.com/forcedotcom/cli/issues/1504). Here's the source-tracking PR: [#295](https://github.com/forcedotcom/source-tracking/pull/295). * FIX: The `force:package:beta:delete --package ` command now correctly deletes a package even if the associated packageAlias is not listed in the `sfdx-project.json` file. As of this release, `force:package:beta:delete` is now `force:package:delete`. (GitHub issue [#1858](https://github.com/forcedotcom/cli/issues/1858), packaging PR [#179](https://github.com/forcedotcom/packaging/pull/179)) * FIX: To keep the new `force:package:version:create` command consistent with its legacy version, we updated the new command so you can use the `--package` and `--path` flags together in a single command execution. However, we also added a warning to say that the usage is deprecated and will be removed in the future. (GitHub issue [#1865](https://github.com/forcedotcom/cli/issues/1865), plugin-packaging PR [#211](https://github.com/salesforcecli/plugin-packaging/pull/211)) * FIX: The `force:package:version:create` command now correctly resolves the package directory when you specify both a package ID with the `--package` flag on the command and as the value for the `package` property in the `packageDirectories` section of `sfdx-project.json`. (GitHub issue [#1865](https://github.com/forcedotcom/cli/issues/1865), plugin-packaging PR [#211](https://github.com/salesforcecli/plugin-packaging/pull/211)) ## 7.182.1 (Dec 22, 2022) * FIX: When deploying or retrieving source to or from an org, Salesforce CLI now strictly enforces [this order of priority](https://github.com/forcedotcom/source-deploy-retrieve/pull/791#issue-1479939776) to determine the value of `apiVersion` and `sourceApiVersion`. As a reminder, `apiVersion` refers to the core Metadata API version used to service the HTTPS request or response via either SOAP or REST; `sourceApiVersion` refers to the shape of the metadata itself. For example, let's say you set the global `apiVersion` configuration value to 55.0 but then run `force:source:deploy` with the `--apiversion 56.0` flag. The command uses 56.0 as the `apiVersion` when deploying. Similarly, say you set the `sourceApiVersion` property in the `sfdx-project.json` file to 57.0, but the `` element in the `package.xml` manifest file is 56.0. The command uses 56.0 as the `sourceApiVersion`. This fix applies to all of these commands: `force:source:deploy|retrieve`, `force:source:push|pull`, and `force:mdapi:deploy|retrieve`. We've also improved the message that's displayed when you deploy or retrieve source with one of these commands. In this sample retrieve message, the `sourceApiVersion` is 54.0, the `apiVersion` is 57.0, and the retrieve uses SOAP API: `Retrieving v54.0 metadata from test-xktpgkdbuyp7@example.com using the v57.0 SOAP API` Yep, we know this API version stuff is tricky. We're in the process of updating the docs with more information and examples. (PRs: SDR [#791](https://github.com/forcedotcom/source-deploy-retrieve/pull/791) and [#797](https://github.com/forcedotcom/source-deploy-retrieve/pull/797), plugin-source [#673](https://github.com/salesforcecli/plugin-source/pull/673)) * FIX: The `auth:list` command correctly displays `No results found` again when it doesn't find any authenticated orgs; previously it printed an empty table. Here's some awesomeness: we put out a call for help with this issue, and [Mounib](https://github.com/aemounib) graciously answered it. Thanks for your (second!) contribution, we look forward to more! (GitHub issue [#1798](https://github.com/forcedotcom/cli/issues/1796), PR plugin-auth [#552](https://github.com/salesforcecli/plugin-auth/pull/552)) * FIX: Salesforce CLI retries the command if it encounters either of these errors from the server during metadata deploy operations: * `INVALID_QUERY_LOCATOR` * `

          Bad Message 400

          reason: Bad Request
          ` (GitHub issues [#1727](https://github.com/forcedotcom/cli/issues/1727) and [#1835](https://github.com/forcedotcom/cli/issues/1835), PR SDR [#792](https://github.com/forcedotcom/source-deploy-retrieve/pull/792)) * FIX: The `force:source:*` commands now support these metdata types used by Net Zero Cloud: * FuelType * FuelTypeSustnUom * SustainabilityUom * SustnUomConversion ## 7.181.1 (Dec 15, 2022) * FIX: Running the command `force:package:beta:version:create:report` on a package that failed to build correctly now displays the full list of errors that caused the package build to fail. (GitHub issue [#1779](https://github.com/forcedotcom/cli/issues/1779), plugin-packaging PR [#181](https://github.com/salesforcecli/plugin-packaging/pull/181)) * FIX: The `sfdx:force:data:record:create|update` commands correctly handle field values passed to the `--values` flag that contain a single or double quote, such as `--values "customfield__c=Won't Fix"`. (GitHub issue [#1820](https://github.com/forcedotcom/cli/issues/1820), plugin-data PR [#427](https://github.com/salesforcecli/plugin-data/pull/427)) * FIX: The `force:org:create` command now correctly displays all errors encountered when attempting to create a sandbox. (plugin-org PR [#517](https://github.com/salesforcecli/plugin-org/pull/517)) ## 7.180.0 (Dec 8, 2022) * NEW: We've worked hard to make the [`sf` executable of Salesforce CLI](../sf/README.md) a whiz-bang developer tool that's also fun to use. We like it so much that we decided to add some of its coolest features to `sfdx` too! Check 'em out: - Use spaces as topic separators, such as `sfdx force org list`. Don't worry, you can still use colons if you prefer, such as `sfdx force:org:list`. * Enter command fragments in any order, using either spaces or colons as separators, and Salesforce CLI figures out what you mean. For example, let's say you want to list all your orgs, but forgot the exact command. All of the following commands work without returning any `command not found` errors: ```bash sfdx force org list sfdx org force list sfdx list force org sfdx force:org:list sfdx org:force:list sfdx list:force:org ``` * Search the `sfdx` commands for that special one you've been looking for all your life with the new interactive `sfdx search` command. * (Changed behavior) The `-h` flag now displays a subset of the full help, specifically the short command and flag descriptions and the command usage. It's great for quick reference information. The `-help` flag continues to display the full help, including long command and flag descriptions and examples. * NEW: If you installed Salesforce CLI with the installers, you can now easily update to an older version with the new `--version` flag. For example, to update to version `7.176.0`: ```bash sfdx update --version 7.176.0 ``` Use the `--available` flag to list all available older versions to which you can update. The output also shows whether you already have a local copy or if it must be downloaded. Use `-interactive` to choose a version interactively. * NEW: Specify the browser to use with the `auth:web:login` command with the new `--browser|-b` parameter. Supported browsers are `chrome`, `edge`, and `firefox`. If you don't specify `--browser`, the authorization page opens in your default browser. For example, to authorize an org in Firefox: `sfdx auth:web:login --browser firefox` Thank you, [Mounib](https://github.com/aemounib), for writing the code for this new feature! We love contributions from the community, and look forward to many more. (GitHub issue [#1465](https://github.com/forcedotcom/cli/issues/1465), plugin-auth PR [#537](https://github.com/salesforcecli/plugin-auth/pull/537)) * FIX: The `force:source:deploy:report` command no longer returns the error `ERROR running force:source:deploy:report: Metadata API request failed: The org cannot be found`. (GitHub issue [#1713](https://github.com/forcedotcom/cli/issues/1713), sfdx-core PR [#712](https://github.com/forcedotcom/sfdx-core/pull/712)) * FIX: The `--retrievetargetdir` flag of the `force:source:retrieve` command is working as expected when retrieving custom labels and when components listed in the manifest don't exist in the org. (GitHub issues [#1827](https://github.com/forcedotcom/cli/issues/1827) and [#1823](https://github.com/forcedotcom/cli/issues/1823), plugin-source PR [#659](https://github.com/salesforcecli/plugin-source/pull/659)) ## 7.179.0 (Dec 1, 2022) * FIX: The command `force:source:deploy` provides more detailed error messages while converting metadata. (GitHub issue [#1420[(https://github.com/forcedotcom/cli/issues/1420), SDR PR [#781](https://github.com/forcedotcom/source-deploy-retrieve/pull/781)) * FIX: The `force:source:push` command no longer deletes the entire zipped Static Resource from the org after you've deleted a single static resource file with from that folder in your project. (GitHub issue [#1589[(https://github.com/forcedotcom/cli/issues/1589), source-tracking PR [#273](https://github.com/forcedotcom/source-tracking/pull/273)) * FIX: The command `force:package:version:create` no longer fails when creating a package version on a package that has a dependency on another package. (GitHub issue [#1742](https://github.com/forcedotcom/cli/issues/1742)) * FIX: Salesforce CLI now correctly performs flag validation that has been specified with a custom `parse` property on a flag. This fix means that when you run a command that has a flag with a custom `parse` property, you now correctly get an error if your passed-in value fails the validation. Previously the invalid value was incorrectly accepted. (command PR [#193](https://github.com/salesforcecli/command/pull/193)) ## 7.178.0 (Nov 24, 2022) * FIX: The `force:source:*` commands support the ExtlClntAppMobileConfigurablePolicies metadata type. ## 7.177.1 (Nov 17, 2022) * FIX: The `force:org:status` command is working correctly and no longer returns the error `MediaType of 'application/json,application/json' is not supported by this resource`. (sfdx-core PR [#697](https://github.com/forcedotcom/sfdx-core/pull/697)) * FIX: The `force:org:create` command correctly fires configured `postorgcreate` hooks. (GitHub issue [#1722](https://github.com/forcedotcom/cli/issues/1722), plugin-org PR [#485](https://github.com/salesforcecli/plugin-org/pull/485)) * FIX: The `force:package:beta:version:create` command includes and installs unpackaged metadata so package version create with code coverage is working correctly. (GitHub issue [#1743](https://github.com/forcedotcom/cli/issues/1743), packaging PR [#117](https://github.com/forcedotcom/packaging/pull/117)) * FIX: The `force:package:beta:version:create` command adds `dependencies` in the `packageDirectories` section of the `sfdx-project.json` file using the correct `package` key rather than the incorrect `subscriberPackageVersionId` key. (GitHub issue [#1764](https://github.com/forcedotcom/cli/issues/1764), packaging PR [#117](https://github.com/forcedotcom/packaging/pull/117)) * FIX: The `force:package:beta:version:create` command correctly creates a package version and no longer returns the error `Converting circular structure to JSON`. (GitHub issue [#1789](https://github.com/forcedotcom/cli/issues/1789)) * FIX: The `force:package:beta:version:list` command correctly outputs the datetime values in the **Created Date** and **Last Modified Date** columns using the user's locale rather than UTC. (GitHub issue [#1794](https://github.com/forcedotcom/cli/issues/1794), plugin-packaging PR [#152](https://github.com/salesforcecli/plugin-packaging/pull/152)) * FIX: The `force:mdapi:deploy` command correctly deploys and returns the expected response. It would unexpectedly exit on very large files in 7.176.1 and 7.177.0. Special thanks to [Andrew Goodman](https://github.com/gdman) for helping find the root cause. (Github issue [#1802](https://github.com/forcedotcom/cli/issues/1802), source-deploy-retrieve PR [#768](https://github.com/forcedotcom/source-deploy-retrieve/pull/768)) ## 7.176.1 (Nov 10, 2022) * NEW: Quickly gather Salesforce CLI configuration data and run diagnostic tests with the new `doctor` command. Use the command to easily generate informational files that you can attach to [GitHub issues](https://github.com/forcedotcom/cli/issues) or provide to Salesforce Customer Support. Run without parameters, the command first displays basic information, such as whether you're on the latest CLI version. It then writes your configuration and a detailed diagnosis to a JSON file in the current directory. Use the `--outputdir` parameter to specify a different directory. For example: `sfdx doctor --outputdir diagnostic-files` Use the `--command` parameter to run a specific command in debug mode; the doctor writes both stdout and stderr to separate `*.log` files. Encapsulate the command in double quotes. For example: `sfdx doctor --command "force:org:list --all"` To run diagnostic tests on a specific plugin rather than the CLI itself, use the `--plugin` parameter. If the plugin isn't listening to the doctor, then you get a warning and no data. `sfdx doctor --plugin @salesforce/plugin-source` We've made it really easy to create a GitHub issue: specify the `--createissue` parameter, enter a title at the prompt, and a browser window automatically opens with a partially-filled GitHub issue. Enter the remaining information about your specific issue, click **Submit new issue**, and you're done. Easy peasy! The CLI doctor is in and ready to diagnose all your problems! * NEW: You can now automatically replace snippets of your metadata source files with specific values right before you deploy the files to an org with the `force:source:deploy|push` commands. This string replacement is "ephemeral" because the changes aren't written to your project; they apply only to the deployed files. Use this new feature to, for example, replace the endpoint in a NamedCredential, depending on whether you're deploying to a production or scratch org. Or specify a password in an ExternalDataSource that you don't want to store in your repo. The use cases are endless! To configure string replacement, add a `replacements` property to your `sfdx-project.json` file and use key-value pairs to describe how the string replacement works. For example, this `sfdx-project.json` snippet specifies that when you deploy the `force-app/main/default/classes/myClass.cls` source file, all occurrences of the string `replaceMe` are replaced with the value of the `THE_REPLACEMENT` environment variable: ```json { "packageDirectories": [ { "path": "force-app", "default": true } ], "name": "myproj", "replacements": [ { "filename": "force-app/main/default/classes/myClass.cls", "stringToReplace": "replaceMe", "replaceWithEnv": "THE_REPLACEMENT" } ] } ``` You can specify these keys in the `replacements` property: * `filename`: Single file that contains the string to be replaced. * `glob`: Collection of files that contain the string to be replaced. Example: `**/classes/*.cls`. * `stringToReplace`: The string to be replaced. * `regexToReplace`: Regular expression that specifies a string pattern to be replaced. * `replaceWithEnv`: Specifies that the string be replaced with the value of the environment variable. * `replaceWithFile`: Specifies that the string be replaced with the contents of a file. * `replaceWhenEnv`: Specifies a condition, using environment variables, for when a string replacement occurs. A few syntax notes: * Always use forward slashes (`/`), even on Windows. * JSON requires that you escape all backlashes (`\`) with another backslash. This example is similar to the previous one, except that the replacement occurs only if an environment variable called `DEPLOY_DESTINATION` exists and it has a value of `PROD`. ```json "replacements": [ { "filename": "force-app/main/default/classes/myClass.cls", "stringToReplace": "replaceMe", "replaceWithEnv": "THE_REPLACEMENT" "replaceWhenEnv": [{ "env": "DEPLOY_DESTINATION", "value": "PROD" }] } ] ``` We’re updating the [Salesforce DX Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_develop.htm) with more details and examples; we’ll let you know when it’s available. * NEW: Retrieve source files into a non-package directory (AKA a directory that _isn't_ configured in your `sfdx-project.json` file) with the new `--retrievetargetdir` parameter of the `force:source:retrieve` command. With this parameter you can now keep your unpackaged source files separate from your packaged files. Then, for example, you can easily prevent these unpackaged files from being deployed to a scratch org because they're not included in any configured package directory. This example shows how to retrieve all Apex classes from your default org and put the source-formatted files into the `unpackaged-files` directory. If this directory doesn't exist, the command creates it for you. Your configured package directories are unchanged. `sfdx force:source:retrieve --retrievetargetdir ./unpackaged-files --metadata ApexClass` Many thanks to [Matthias Rolke](https://github.com/amtrack) for suggesting the cool feature, and then writing a lot of the code! [plugin-source PR #426](https://github.com/salesforcecli/plugin-source/pull/426) * CHANGE: We upgraded the version of Node.js contained in the full Salesforce CLI Docker image to LTS v18. (sfdx-cli PR [#720](https://github.com/salesforcecli/sfdx-cli/pull/720)) * FIX: The `force:source:*` commands now support these metdata types: * ExtlClntAppOauthConfigurablePolicies (previously called ExtlClntAppOauthPlcyCnfg) * ExtlClntAppMobileSettings (previously called ExtlClntAppMobileSet) * FIX: StaticResources now deploy correctly; in the previous version of this week's RC (7.176.0) the deploy command would immediately exit. Special thanks to [David Esposito](https://github.com/daveespo) for building a nightly pipeline that uses the RC, and for debugging and reporting the issue so quickly and with a perfect repro. [#1791](https://github.com/forcedotcom/cli/issues/1791). ## 7.175.0 (Nov 3, 2022) * FIX: The `force:source:*` commands now support these metadata types: * BotBlock * ClauseCatgConfiguration * DisclosureType * DisclosureDefinition * DisclosureDefinitionVersion * ExtlClntAppOauthPlcyCnfg * ExtlClntAppOauthSettings * ExtlClntAppMobileSet * OmniSupervisorConfig * FIX: We've improved the error message thrown by the `force:source` commands when they encounter an invalid metadata type when parsing a manifest file, such as `package.xml`. (GitHub issue [#1187](https://github.com/forcedotcom/cli/issues/1187), SDR PR [#740](https://github.com/forcedotcom/source-deploy-retrieve/pull/740)) * FIX: The `force:package:beta:version:create` command is working correctly and no longer returns the error `Cannot read properties of undefined (reading 'package')`. (GitHub issue [#1750](https://github.com/forcedotcom/cli/issues/1750), plugin-packaging PR [#129](https://github.com/salesforcecli/plugin-packaging/pull/129)) ## 7.174.0 (Oct 27, 2022) * CHANGE: The [Docker images](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_docker.htm) we publish each week now run a more recent version of Ubuntu. Additionally, the `full` images run a more recent minor version of Node.js 16. For details about the supported runtime versions, see the [documentation about the Heroku-20 Stack](https://devcenter.heroku.com/articles/heroku-20-stack), which is the new parent image of our Salesforce CLI Docker images. * FIX: The `force:source:push` command now correctly returns a non-zero exit code when it encounters a [GACK](https://developer.salesforce.com/blogs/tag/gack) and displays the full internal error message. The `force:source:deploy` and `force:mdapi:deploy` commands were already returning a non-zero exit code in this case. But they now also display the full message; previously you had to use the `--json` flag to view it. ## 7.173.0 (Oct 20, 2022) * FIX: The `force:apex:test:run|report -r junit` commands now produce valid XML output. (GitHub issue [#280](https://github.com/forcedotcom/salesforcedx-apex/issues/280), salesforcedx-apex PR [#285](https://github.com/forcedotcom/salesforcedx-apex/pull/285)) * FIX: The `force:source:*` commands now support these metadata types: * CallCtrAgentFavTrfrDest * ExternalCredential * MarketSegmentDefinition * MfgProgramTemplate * StreamingAppDataConnector * FIX: The `force:org:create` command now throws a better error message when it's run against an org that is not a DevHub. (GitHub PR https://github.com/forcedotcom/sfdx-core/pull/669) ## 7.172.0 (Oct 13, 2022) * FIX: The `force:source:push` and `force:source:deploy` commands correctly deploy any CustomFieldTranslation metadata types that have local changes. (PRs: source-deploy-retrieve [#726](https://github.com/forcedotcom/source-deploy-retrieve/pull/726) and [#728](https://github.com/forcedotcom/source-deploy-retrieve/pull/728), plugin-source [#597](https://github.com/salesforcecli/plugin-source/pull/597), source-tracking [#243](https://github.com/forcedotcom/source-tracking/pull/243)) * FIX: The `force:mdapi:deploy` command correctly handles the new enhanced domains in Winter '23 preview sandboxes. [GitHub issue [#1687](https://github.com/forcedotcom/cli/issues/1687). PRs: jsforce [#1272](https://github.com/jsforce/jsforce/pull/1272), sfdx-core [#667](https://github.com/forcedotcom/sfdx-core/pull/667)) * FIX: The `force:source:*` commands now support the RelationshipGraphDefinition metadata type. [PR: source-deploy-retrieve [#722](https://github.com/forcedotcom/source-deploy-retrieve/pull/722)) ## 7.171.0 (Oct 6, 2022) * FIX: The `force:org:create` command now respects the `apiVersion` config value. (GitHub issue [#1719](https://github.com/forcedotcom/cli/issues/1719), sfdx-core PR [#656](https://github.com/forcedotcom/sfdx-core/pull/656)) ## 7.170.0 (Sept 29, 2022) * FIX: We fixed some under-the-hood bugs. ## 7.169.1 (Sept 22, 2022) * CHANGE: We've completed [open-sourcing](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) the packaging commands and created these new beta commands in the new [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) plug-in: * `force:package:beta:uninstall:report` * `force:package:beta:version:displayancestry` These beta commands work the same as their equivalent existing commands. Now that we've created open-source beta versions of all the packaging commands, we no longer maintain the current implementations of the `force:package:*` commands. We recommend that you start testing the equivalent `force:package:beta:*` commands, which are functionally the same. If you run into issues with the current commands, first try the equivalent `force:package:beta` command to see if your issue is fixed. If it isn't, file a report against the `force:package:beta:*` command on https://github.com/forcedotcom/cli/issues. The same applies to the `force:package1:*` commands. We plan to make the beta commands generally available in the near future. * FIX: The `force:source:*` commands now support these metadata types: * DigitalExperienceBundle * DigitalExperience * DigitalExperienceConfig * FIX: Any registered `postorgcreate` hooks, which fire immediately after a new scratch org or sandbox is created, no longer fire twice. (GitHub issue [#1700](https://github.com/forcedotcom/cli/issues/1700), plugin-org PR [#391](https://github.com/salesforcecli/plugin-org/pull/391)) * FIX: You can now correctly deploy empty metadata files; previously you'd get an UNKNOWN_EXCEPTION error. (GitHub issue [#1673](https://github.com/forcedotcom/cli/issues/1673), SDR PR [#705](https://github.com/forcedotcom/source-deploy-retrieve/pull/705)) ## 7.168.0 (Sept 14, 2022) * FIX: The `force:source:*` commands now support these metadata types: * ExternalClientApplication * ForecastingFilter * ForecastingFilterCondition * SchedulingObjective ## 7.167.2 (Sept 8, 2022) * CHANGE: We continue on our [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) project with the packaging commands. We've created these new beta commands in the new [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) plug-in: * `force:package:beta:version:list` * `force:package:beta:version:update` * `force:package:beta:update` These beta commands work the same as their equivalent existing commands. Try out these beta commands before we make the open-source versions generally available. * FIX: The `force:source:*` commands now support the MarketingAppExtension metadata type. ## 7.166.1 (Sept 1, 2022) * CHANGE: Our journey to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) is coming to an end; the finish line is in sight. This week we've created these beta commands in the new [plugin-packaging](https://github.com/salesforcecli/plugin-packaging) plug-in: * `force:package:beta:create` * `force:package:beta:delete` * `force:package:beta:install` * `force:package:beta:install:report` * `force:package:beta:installed:list` * `force:package:beta:list` * `force:package:beta:uninstall` * `force:package:beta:version:create` * `force:package:beta:version:create:list` * `force:package:beta:version:create:report` * `force:package:beta:version:delete` * `force:package:beta:version:promote` * `force:package:beta:version:report` * `force:package1:beta:version:create` * `force:package1:beta:version:create:get` * `force:package1:beta:version:display` * `force:package1:beta:version:list` These new beta commands work the same as their equivalent existing commands. Try out these beta commands before we make the open-source versions generally available. ## 7.165.0 (Aug 25, 2022) * NEW: When we publish the `sfdx` executable of Salesforce CLI to npm, we lock down its dependencies. As a result, users installing `sfdx` from npm get immutable builds. See [Locking dependencies with npm shrinkwrap](https://github.com/forcedotcom/cli/issues/1678) for details. ## 7.164.2 (Aug 18, 2022) * NEW: Retrieve more records when running `force:data:soql:query` with the new `--bulk` parameter, which makes the command use Bulk API 2.0 for the SOQL query. Bulk API 2.0 has higher limits than the default API used by the command. The default maximum number of records returned by the command is 10,000, so use `--bulk` if your SOQL query returns more. When using `--bulk`, the command waits 3 minutes by default for the query to complete. Use the new `--wait` parameter to specify a different number of minutes to wait, or set it to 0 to immediately return control to the terminal. For example, to not wait for the query to complete: `sfdx force:data:soql:query --query --bulk --wait 0` But hold on a second; if you don't wait for the query to complete, how do you get the results? We thought of that! The preceding command displays an ID that you then pass to the new `force:data:soql:bulk:report` command with the `--bulkqueryid` parameter. Use the optional `--resultformat` parameter to specify the format of the results, such as `csv` or `json`. For example: `sfdx force:data:soql:bulk:report --bulkqueryid 75000woohoo00XXX --resultformat json` Many thanks to [Colin Casey](https://github.com/colincasey) for contributing part of this cool new feature. And to [Doug Ayers](https://github.com/forcedotcom/cli/issues/1223) for requesting it. * NEW: The new open-source `force:org:create` command, which lives in the [plugin-org](https://github.com/salesforcecli/plugin-org) plug-in, is now generally available. This means that the changes we made to the beta version (`force:org:beta:create`) are now in `force:org:create`. The functionality in the _old_ `force:org:create` is now in `force:org:legacy:create`. The new command is functionally the same as the old one. In the short term, you can use the `force:org:legacy:create` command if you run into issues with the new command. * CHANGE: The `force:source:*` commands no longer support these metadata types associated with Connect Center: * ConnectedSystem * DataMapping * DataMappingObjectDefinition * DataMappingSchema * DataMappingFieldDefinition * FederationDataMappingUsage * FIX: (7.164.2) The `force:org:create` command supports mixed-case usernames when you pass them as org definition values at the command line. For example: `sfdx force:org:create username=MixedCaseName@mycompany.com --setdefaultusername -f config/project-scratch-def.json` In the first patch of this release candidate, the command returned a `No authorization information found` error. Big thanks to [David Esposito](https://github.com/daveespo) for finding and reporting the issue ([GH #1669](https://github.com/forcedotcom/cli/issues/1669)). This is a major reason we create release candidates: so the community can find these little regressions early, and we can fix 'em ([plugin-org](https://github.com/salesforcecli/plugin-org/pull/384)) before they make it into our stable release. Nice work everyone! * FIX: Running the `force:source:push` command on a large project with many files no longer returns the `EMFILE: too many open files` error. A second happy result of this fix is better command performance. (GitHub issue [#1555](https://github.com/forcedotcom/cli/issues/1555), [SDR PR #683](https://github.com/forcedotcom/source-deploy-retrieve/pull/683)) * FIX: The `force:source:deploy` command works correctly during Salesforce release transition periods, such as the current transition from API version 55.0 to 56.0. (GitHub issue [#1656](https://github.com/forcedotcom/cli/issues/1656), [SDR PR #684](https://github.com/forcedotcom/source-deploy-retrieve/pull/684)) * FIX: The `force:source:status` command shows properly filtered results based on your `.forceignore` file. ([source-tracking PR #195](https://github.com/forcedotcom/source-tracking/pull/195)) ## 7.163.0 (Aug 11, 2022) * FIX: We fixed some under-the-hood bugs. ## 7.162.0 (Aug 4, 2022) * NEW: Run large SOQL queries and avoid your operating system's command character limit with the new `--soqlqueryfile` parameter of the `force:data:soql:query` command. Create a text file that contains your SOQL query, then specify the file with the parameter. For example: `sfdx force:data:soql:query --soqlqueryfile query.txt -u my-org` (GitHub issue [#360](https://github.com/forcedotcom/cli/issues/360), [plugin-data PR #327](https://github.com/salesforcecli/plugin-data/pull/327)) * FIX: The `force:org:clone` command clones a sandbox org without errors. (GitHub issue [#1637](https://github.com/forcedotcom/cli/issues/1637), [sfdx-core PR #623](https://github.com/forcedotcom/sfdx-core/pull/623)) * FIX: The `force:mdapi:convert` command converts CustomLabels metadata types to source format. (GitHub issue [#1540](https://github.com/forcedotcom/cli/issues/1540), SDR PRs [#660](https://github.com/forcedotcom/source-deploy-retrieve/pull/660), [#666](https://github.com/forcedotcom/source-deploy-retrieve/pull/666)) * FIX: The `force:org:list` command displays scratch orgs that have additional users created in them. (GitHub issue [#1641](https://github.com/forcedotcom/cli/issues/1641), [plugin-org PR #359](https://github.com/salesforcecli/plugin-org/pull/359)) * FIX: The `force:data:tree:export` command no longer converts the SOQL query that you pass it with the `-q` parameter to lowercase. (GitHub issue [#1642](https://github.com/forcedotcom/cli/issues/1642), [plugin-data PR #330](https://github.com/salesforcecli/plugin-data/pull/330)) Many thanks to [Anthony Heber](https://github.com/aheber) for your fix. Our community comes through again. Keep 'em coming! ## 7.161.0 (July 28, 2022) * FIX: When `mdapi:deploy:report` and `source:deploy:report` exceed their `--wait` limit, they return a JSON error that contains the expected deploymet details. (GitHub issue [#1612](https://github.com/forcedotcom/cli/issues/1612), [plugin-source PR #538](https://github.com/salesforcecli/plugin-source/pull/538)) * FIX: The `force:org:beta:create` command sets aliases correctly. (GitHub issue [#1630](https://github.com/forcedotcom/cli/issues/1630), [sfdx-core PR #620](https://github.com/forcedotcom/sfdx-core/pull/620) and [plugin-org PR #357](https://github.com/salesforcecli/plugin-org/pull/357)) * FIX: The older `force:org:create` command was missing some error messages. (GitHub issue [#1638](https://github.com/forcedotcom/cli/issues/1638)) * FIX: Pushing invalid LWC templates with the `force:source:push` command to scratch orgs that have a namespace now returns proper errors. (GitHub issue [#1602](https://github.com/forcedotcom/cli/issues/1602), [SDR PR #669](https://github.com/forcedotcom/source-deploy-retrieve/pull/669)) * FIX: Authorizing orgs now works with either the HTTPS_PROXY or HTTP_PROXY environment variable. (Github issue [#1626](https://github.com/forcedotcom/cli/issues/1626), [jsforce PR #1256](https://github.com/jsforce/jsforce/pull/1256)) * FIX: The `force:source:*` commands now support these metadata types: * IdentityVerificationProcDef * ServiceAISetupDefinition * ServiceAISetupField ## 7.160.0 (July 21, 2022) * FIX: Refreshing expired access tokens is working as expected. (GitHub issue [#1615](https://github.com/forcedotcom/cli/issues/1615), [sfdx-core PR #619](https://github.com/forcedotcom/sfdx-core/pull/619)) * FIX: The `force:source:*` commands now support these metadata types: * AIUsecaseDefinition * DataPackageKitDefinition * DataPackageKitObject * DataSourceBundleDefinition * DataSrcDataModelFieldMap * DataStreamTemplate ## 7.159.0 (July 14, 2022) * FIX: The `force:org:beta:create` command creates a scratch org when the definition file contains an `objectSettings` entry. (GitHub issue #[1526](https://github.com/forcedotcom/cli/issues/1526)) * FIX: The `force:source:deploy` command respects the `restDeploy` configuration value. (GitHub issue #[1606](https://github.com/forcedotcom/cli/issues/1606)) * FIX: We've strengthened our proxy support so that commands run correctly when behind a company firewall or web proxy. (GitHub issue #[1597](https://github.com/forcedotcom/cli/issues/1597)) ## 7.158.1 (July 7, 2022) * FIX: The `force:org:open` command no longer times out while resolving the Lightning Experience-enabled custom domain in new sandboxes. (GitHub issue #[1556](https://github.com/forcedotcom/cli/issues/1556), #[1603](https://github.com/forcedotcom/cli/issues/1603)) * FIX: Authentication tokens are now consistently and correctly encrypted or decrypted. (GitHub issue #[1314](https://github.com/forcedotcom/cli/issues/1314)) * FIX: The `force:package1:version:list` command displays correct output. (GitHub issue #[1569](https://github.com/forcedotcom/cli/issues/1569)) ## 7.157.0 (June 30, 2022) * FIX: The `force:org:create` command no longer emits a warning about `rmdirSync` being deprecated. (Pull Request [salesforcecli/toolbelt#256](https://github.com/salesforcecli/toolbelt/pull/256)) * FIX: The `force:source:status` command now correctly respects all forceignored files when using the `--concise` parameter. (GitHub issue #[1545](https://github.com/forcedotcom/cli/issues/1545)) ## 7.156.1 (June 23, 2022) * FIX: The `force:data:soql:query` command no longer limits the number of returned records to 2000; it once again uses the default value of 10K. (GitHub issue #[1543](https://github.com/forcedotcom/cli/issues/1543)) * FIX: The `force:mdapi:deploy` command successfully deploys large metadata directories. (GitHub issue #[1531](https://github.com/forcedotcom/cli/issues/1531)) * FIX: You can now run the `force:mdapi:deploy` command on a production org without specifying the `--testlevel` parameter if your project doesn't contain any Apex classes. Previously it incorrectly failed with the error `INVALID_OPERATION: testLevel of NoTestRun cannot be used in production organizations`. (GitHub issue #[1542](https://github.com/forcedotcom/cli/issues/1542)) * FIX: Username aliases now resolve correctly. Previously, when using an alias instead of a username in some commands in certain conditions, you'd get errors such as: * `No authorization information found for ` * `ERROR running force:package:version:create: Missing config object` (GitHub issues #[1576](https://github.com/forcedotcom/cli/issues/1576) and #[1577](https://github.com/forcedotcom/cli/issues/1577)) ## 7.155.1 (June 16, 2022) * NEW: Org Shape for Scratch Orgs is generally available. Use these org shape commands to create a scratch org configuration (shape) based on a specific source org and then manage it: * `force:org:shape:create` * `force:org:shape:delete` * `force:org:shape:list` See [Create a Scratch Org Based on an Org Shape](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm) for details. * FIX: We've improved the `auth:jwt:grant` command so that it succeeds more often on more types of orgs. * FIX: We've improved the `force:source` and `force:mdapi` commands so they catch a common Metadata API fault and then retry the deploy or retrieve if necessary. (GitHub issue #[1522](https://github.com/forcedotcom/cli/issues/1522)) ## 7.154.0 (June 9, 2022) * FIX: The package dependency keyword `LATEST` no longer resolves to a deleted package version. (GitHub issue [#1514](https://github.com/forcedotcom/cli/issues/1514)) ## 7.153.0 (June 2, 2022) * NEW: Get the results of your Apex tests in JUnit format, and code coverage results in a variety of formats, with three new parameters for these commands: * `force:source:deploy` * `force:source:deploy:report` * `force:mdapi:deploy` * `force:mdapi:deploy:report` Use the new Boolean `--junit` parameter to specify you want JUnit-style results of your Apex tests. Use `--coverageformatters` to specify one or more formats for the code coverage information; if you don't specify the parameter, no code coverage information is generated. The possible values for this flag are: * `clover` * `cobertura` * `html-spa` * `html` * `json` * `json-summary` * `lcovonly` * `none` * `teamcity` * `text` * `text-summary` Use the `--resultsdir` parameter to specify the name of the directory in which the results are written; the default value is the deployment ID. When the command completes, the results directory contains two subdirectories; `junit` and `coverage`. The `junit` directory contains a single file called `junit.xml` with the JUnit-formatted test results. The `coverage` directory contains files for each code coverage format you specified. This example shows how to deploy the metadata source in the `force-app` directory and run all Apex tests in the org. When the depoy completes, the Apex test results are written in JUnit format to the `test-results/junit/junit.xml` file. Code coverage information is in two files: `test-results/coverage/clover.xml` and `test-results/coverage/cobertura.xml`. ```bash sfdx force:source:deploy -p force-app --testlevel RunAllTestsInOrg --junit --coverageformatters clover,cobertura --resultsdir test-results ``` * FIX: The `force:source:*` commands now support the BotTemplate metadata type. ## 7.152.0 (May 26, 2022) * FIX: We fixed some under-the-hood bugs. ## 7.151.1 (May 19, 2022) * CHANGE: The project to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) continues to speed along. This week we moved these commands into their own plug-ins: * `force:org:snapshot:create|delete|get|list`: Moved to [plugin-signups](https://github.com/salesforcecli/plugin-signups). * `force:org:clone`: Moved to [plugin-org](https://github.com/salesforcecli/plugin-org). We've improved the stability of the `force:org:clone` command. All the commands work the same as before. * FIX: The `force:data:soql:query` command correctly displays the values from multiple relationship fields. (GitHub issue [#1473](https://github.com/forcedotcom/cli/issues/1473)) * FIX: The `force:data:soql:query -r csv -q` command returns a blank for null fields; previously the command return the `null` string. (GitHub issue [#1447](https://github.com/forcedotcom/cli/issues/1447)) * FIX: The `force:source:*` commands now support these metadata types: * AssessmentQuestion * AssessmentQuestionSet * DataWeaveResource * FIX: Creating manifests with `force:source:manifest:create --fromorg` now works correctly when metadata components don't have a usable `path`. (Github issue [#1492](https://github.com/forcedotcom/cli/issues/1492)). This fix is a perfect example of why we're open-sourcing Salesforce CLI, because the bug was: * related to a feature originally created by [Jochen Rinder](https://github.com/jayree) * found and reported by [Rupert Barrow](https://github.com/RupertBarrow) * replicated and fixed in a PR by [Anthony Heber](https://github.com/aheber) * FIX: Passing `--wait -1` to certain `force:mdapi` commands now causes them to wait indefinitely for the operation to complete. This functionality matches that of the corresponding `force:mdapi:legacy` commands. (GitHub issues [#1508](https://github.com/forcedotcom/cli/issues/1508), [#1511](https://github.com/forcedotcom/cli/issues/1511), and [#1519](https://github.com/forcedotcom/cli/issues/1519)) * FIX: Using `debug` logs on `force:mdapi:deploy` no longer throws a `Converting circular structure to JSON` error. (GitHub issue [#1518](https://github.com/forcedotcom/cli/issues/1518)) ## 7.150.0 (May 12, 2022) * NEW: After a successful beta and incorporating feedback from our community, the following commands that used to be in the `force:mdapi:beta` topic are now generally available: * `force:mdapi:deploy` * `force:mdapi:retrieve` * `force:mdapi:deploy:report` * `force:mdapi:retrieve:report` * `force:mdapi:convert` What does this mean? The functionality we added to `force:mdapi:beta:deploy`, for example, is now in `force:mdapi:deploy`. The functionality in the _old_ `force:mdapi:deploy` is now in `force:mdapi:legacy:deploy`. In the short term, you can use these `force:mdapi:legacy` commands if you run into issues with the new commands. The new commands are open-source and live in the [plugin-source](https://github.com/salesforcecli/plugin-source) plug-in. These changes to `force:mdapi:beta` commands, mentioned in older release notes entries, now apply to their GA versions: * The `force:mdapi:retrieve` command now generates a correct `package.xml` file that you can then use for deploying. * Get shorter JSON output from running the `force:mdapi:deploy` or `force:mdapi:deploy:report` commands by using the new `--concise` parameter with the `--json` parameter. The new parameter omits success messages from the JSON output. * When running `force:mdapi:deploy`, specify that deleted components in the destructive changes manifest file are immediately eligible for deletion with the new `--purgeondelete` parameter. By default, deleted components are stored in the Recycle Bin. * Automatically extract files from the retrieved `.zip` file with the new `--unzip` parameter of the `force:mdapi:retrieve` and `force:mdapi:retrieve:report` commands. Use the `--zipfilename` parameter to specify a name for the retrieved `.zip` file. * We've improved the performance of the `force:mdapi:convert` command and added a spinner that shows the progress of the conversion. * CHANGE: We updated the `force:package:version:report --verbose` command to display a list of Apex classes that aren't passing code coverage requirements. For more details see [Determine Which Apex Classes Have Insufficient Code Coverage](https://help.salesforce.com/s/articleView?id=release-notes.rn_packaging_apex_code_coverage.htm&type=5&release=238) in Salesforce Release Notes. ## 7.149.1 (May 5, 2022) * CHANGE: We updated the command-line help of `force:org:list --clean` to explain that the command doesn't delete non-scratch orgs. Props to @jclark-dot-org for the [feedback](https://github.com/salesforcecli/plugin-org/pull/318). * FIX: `force:source:pull` now ignores certain files in your `.forceignore` when the files don't exist locally. Thank you @ImJohnMDaniel for [reporting the issue](https://github.com/forcedotcom/cli/issues/1471) with an excellent repro! * FIX: `force:source:pull` doesn't create duplicate files that you have in your default directory but not under `main/default`. More credit to @ImJohnMDaniel for [noticing the problem](https://github.com/forcedotcom/cli/issues/1485). * FIX: `force:source:push` correctly pushes LWC subfolders such as `force-app/lwc/foo/lwc/myLWC/**`. Thank you @yippie for [reporting](https://github.com/forcedotcom/cli/issues/1477) :bow:. * FIX: Deploys that time out now [include the deploy ID](https://github.com/forcedotcom/source-deploy-retrieve/pull/614), making various automations possible that previously required workarounds. * FIX: `force:data` commands no longer throw [schema validation errors](https://github.com/forcedotcom/cli/issues/1493) for npm-based installations. ## 7.148.3 (April 29, 2022) > Note: we normally release on Thursdays, so you'd expect this to say April 28. But since that's also day 2 of TDX, so we'll do the normal release stuff on Friday this week. * CHANGE: We no longer support v12 of Node.js because of its fast approaching end-of-life ([April 30, 2022](https://nodejs.org/en/about/releases/)). We bundle Node.js in each operating system-specific Salesforce CLI installer. We include the Active LTS version of Node.js and update it in tandem with the Node.js release schedule. If you prefer to install Salesforce CLI using `npm`, we recommend you also use the Active LTS version of Node.js. * FIX: If you run `force:source:deploy` with the `--json` parameter and it times out, the JSON error now includes the deployment ID in the `data` property. Use this ID in your scripts to do fancy tricks to handle the timeout. Because we know our customers are experts at fancy tricks! ```bash { "data": { "id": "OAf7Q00000AfTMjSAN" } } ``` ## 7.147.1 (April 21, 2022) * CHANGE: What's that sound, you ask? It's the whoosh of the [Salesforce CLI open-sourcing](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) train zipping along. This week we moved these commands into the [plugin-signups](https://github.com/salesforcecli/plugin-signups) plug-in: * `force:org:shape:create` * `force:org:shape:delete` * `force:org:shape:list` The [Org Shape for Scratch Orgs](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm) feature is still beta. The commands work the same as before they moved into their own plug-in. * FIX: The `force:org:create` command successfully creates a scratch org when the `sfdx-project.json` file contains any of these options in the `packageDirectories` section: * `"ancestorVersion":"HIGHEST|NONE"` * `"ancestorId":"HIGHEST|NONE"` (GitHub issue [#1392](https://github.com/forcedotcom/cli/issues/1392)) * FIX: The `force:data:bulk:upsert` command now breaks up a batch if it exceeds the max limit of 10MB characters per batch, even if the batch is below the other limit of 10K records. This fix is particular helpful if your CSV file contains extra long lines, such as when upserting large text fields. Many thanks to [Anthony Heber](https://github.com/aheber) who submitted the GitHub issue, and then went ahead and fixed it. Our awesome community comes through again! (GitHub issue [#1460](https://github.com/forcedotcom/cli/issues/1460)) * FIX: The URLs to download the release candidates of Salesforce CLI in `.tar.xz` format are now pointing to the most recent versions. (GitHub issue [#1478](https://github.com/forcedotcom/cli/issues/1478)) ## 7.146.0 (April 14, 2022) * FIX: The `force:source:retrieve` and `force:source:pull` commands correctly handle these metadata types: * AppointmentAssignmentPolicy * AppointmentSchedulingPolicy * CustomSite * DataSource * FieldRestrictionRule * IndustriesManufacturingSettings * IntegrationHubSettings * ObjectHierarchyRelationship * RestrictionRule (GitHub issue [#1448](https://github.com/forcedotcom/cli/issues/1448)) * FIX: The `force:source:deploy` and `force:source:push` commands correctly handle metadata files that contain CDATA sections, such as ` Hello

          ]]>          `. (GitHub issue [#1467](https://github.com/forcedotcom/cli/issues/1467)) ## 7.145.0 (April 7, 2022) * FIX: Setting your default Dev Hub while authorizing it now immediately propagates to your whole CLI environment. As a result, valid scratch org deletions no longer occasionally fail with error `Unable to associate this scratch org with a DevHub`. (GitHub issue [#1423](https://github.com/forcedotcom/cli/issues/1423)) * FIX: The `force:source:*` commands now support these metadata types: * DecisionMatrixDefinition * DecisionMatrixDefinitionVersion * ExpressionSetDefinitionVersion * ExpressionSetDefinition ## 7.144.2 (March 31, 2022) Before we describe the changes in this week's release candidate, we have an announcement for our plug-in developers. We published new major versions of the core Salesforce CLI npm packages `@salesforce/command` and `@salesforce/core`. We're slowly migrating the core Salesforce CLI plug-ins to these new npm package versions. The migration is strictly under-the-covers and won’t have any public-facing changes. To stay current, consider migrating your plug-ins soon too. * [@salesforce/command](https://github.com/salesforcecli/command): Upgraded to version 5. Contains the `SfdxCommand` class, which is the base class that all Salesforce CLI commands extend to access useful CLI functionality. To be honest, there aren't many changes in this new version, we upgraded it mostly for bookkeeping purposes. * [@salesforce/core](https://github.com/forcedotcom/sfdx-core/tree/v3): Upgraded to version 3. Library that provides client-side management of Salesforce DX projects, org authentication, connections to Salesforce APIs, and other core functionality. We've made lots of changes in version 3, see [this page](https://github.com/forcedotcom/sfdx-core/blob/v3/MIGRATING_V2-V3.md) for details. Note: As of today, version 3 is still in its own v3 branch and not yet merged into main, although we plan to merge it soon. --- One more announcement, and then I promise we'll get to the new and changed features in this release. As a security best practice, we highly recommend that the refresh tokens in your authorized orgs expire after 90 days (max). You configure this expiration policy in the connected app you use when you authorize the org. * The recommended way to configure this policy is to [create your own connected app](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_connected_app.htm) and set the [Refresh Token Policy field](https://help.salesforce.com/s/articleView?id=sf.connected_app_manage_oauth.htm&type=5) to expire in 90 days or less. You then specify this connected app with the `--clientid` parameter when you authorize an org with either [auth:web:login](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_web_flow.htm) or [auth:jwt:grant](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth_jwt_flow.htm). * If you already authorized an org with `auth:web:login` and didn’t specify the `–clientid parameter`, we created a default connected app in the org called **Salesforce CLI**. However, its refresh tokens are set to _never_ expire. To continue using this default connected app in a secure way, first [install it](https://help.salesforce.com/s/articleView?id=sf.connected_app_how_to_install.htm&type=5), and then edit its policies. We're in the process of updating the [Authorization](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_auth.htm) documentation with these recommendations. Okay, now back to our regularly scheduled programming. --- * NEW: The following commands that used to be in the `force:source:beta` topic are now generally available: * `force:source:push` * `force:source:pull` * `force:source:status` * `force:source:tracking:clear` * `force:source:tracking:reset` See [these notes](./README.md#71400-march-3-2022) for details. * CHANGE: As part of the fix for [GitHub issue #1408](https://github.com/forcedotcom/cli/issues/1408), Salesforce CLI now uses rotating log files. By default, every day at midnight the CLI makes a backup copy of the log file and then clears out its entries to start afresh. This new behavior ensures that the log file doesn't get too big. We keep backups for the past two days along with the current day’s logs. Change the default behavior with these new environment variables: * SFDX_LOG_ROTATION_PERIOD: How often a new log file is created. For example, a value of `1d` means a new log file is created daily, at midnight. A value of `2w` creates a new file every 2 weeks. See the _period_ entry in [this table](https://github.com/forcedotcom/node-bunyan#stream-type-rotating-file) for other options. Default value is `1d`. * SFDX_LOG_ROTATION_COUNT: Number of backup files to keep. Default value is `2`. For example, if you choose a rotation period of 2 weeks and a count of 2, you always have backups for the four weeks before the first entry in the current log. We're also changing the name and location of the log file from `HOME_DIR/.sfdx/sfdx.log` to `HOME_DIR/.sf/sf.log`. This change will happen gradually over the coming months as we update the core Salesforce CLI plug-ins to v3 of[@salesforce/core](https://github.com/forcedotcom/sfdx-core/tree/v3). * FIX: The JSON output when a `force:source:beta:*` command encounters an error now matches the structure of the JSON output of their existing non-beta equivalents. (GitHub issue [#1431](https://github.com/forcedotcom/cli/issues/1431)). * FIX: The `force:mdapi:beta:retrieve` command now generates a correct `package.xml` file that you can then use for deploying. Previously, the `package.xml` file sometimes included an incorrect `undefined` element; the element is now omitted unless it exists in the org. [Jochen Rinder](https://github.com/jayree), you're going to put us out of work. Once again, you didn't just find and report the problem, you then jumped in and submitted a PR to fix it. Thanks a bunch! ## 7.143.0 (March 24, 2022) * FIX: We improved the performance of the `force:source:beta:push` command when pushing a large set of files (many thousands). We also fixed the recent performance regression in the `force:source:tracking:reset` command. (GitHub issues [#1394](https://github.com/forcedotcom/cli/issues/1394), [#1427](https://github.com/forcedotcom/cli/issues/1427)) ## 7.142.1 (March 17, 2022) * FIX: We fixed some under-the-hood bugs. ## 7.141.1 (March 10, 2022) * CHANGE: Due to unexpected issues, we reverted the GA of the `force:source:beta:*` commands that we announced on [March 3, 2022](https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md#71400-march-3-2022-stable). As a result, for example: * `force:source:status` now uses the old pre-Beta functionality. * `force:source:legacy:status` also uses the old functionality. * We readded the `force:source:beta:status` command, which uses the new Beta functionality described in [this release note](https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md#71400-march-3-2022-stable). The same change applies to all of these commands: * `force:source:push` * `force:source:pull` * `force:source:status` * `force:source:tracking:clear` * `force:source:tracking:reset` We apologize for the inconvenience and confusion. (GitHub issue [#1431](https://github.com/forcedotcom/cli/issues/1431)) * CHANGE: The project to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) marches along. This week we moved the `force` command into the [plugin-info](https://github.com/salesforcecli/plugin-info) plug-in. * FIX: The `force:source:*` commands now support these metadata types: * ActivationPlatform * AdvAcctForecastDimSource * ApplicationSubtypeDefinition * AppointmentAssignmentPolicy * BusinessProcessTypeDefinition * CareLimitType * DataConnectorIngestApi * DataSourceTenant * ESignatureConfig * ESignatureEnvelopeConfig * ExplainabilityActionDefinition * ExplainabilityActionVersion * InternalDataConnector * MobSecurityCertPinConfig * MobileSecurityAssignment * MobileSecurityPolicy * MobileSecurityPolicySet * OmniInteractionAccessConfig * ProductAttributeSet * RecordAlertCategory * RecordAlertDataSource ## 7.140.0 (March 3, 2022) * NEW: After a successful beta and great feedback from our community, the following commands that used to be in the `force:source:beta` topic are now generally available: * `force:source:push` * `force:source:pull` * `force:source:status` * `force:source:tracking:clear` * `force:source:tracking:reset` What does this mean? The functionality we added to `force:source:beta:push`, for example, is now in `force:source:push`. The functionality in the _old_ `force:source:push` is now in `force:source:legacy:push`. In the short term, you can use these `force:source:legacy` commands if you run into issues with the new commands. The new commands continue to live in the open-source [plugin-source](https://github.com/salesforcecli/plugin-source) plug-in and use the open-source [source-tracking library](https://github.com/forcedotcom/source-tracking). This library provides direct interaction with your local source-tracking files using git. The commands also use the open-source and better-performing [source-deploy-retrieve](https://github.com/forcedotcom/source-deploy-retrieve) library, just like VSCode and the `force:source:deploy|retrieve` commands. A word of warning: we changed the format of the internal files the commands use to track your source. We also store them in different locations than the old commands. As a result, you can’t use the old source-tracking files with the new commands. You have a few options: * If you want to use the new commands with an existing scratch org or sandbox, run `force:source:legacy:tracking:clear` or `force:source:legacy:tracking:reset`. If you try to use an existing org without resetting or clearing its tracking files, we display an error and tell you which command to run. * Create a scratch org or sandbox, which doesn’t have any associated source-tracking files yet. * Keep using the `force:source:legacy:*` commands until you’re ready to make the switch to the new commands using one of the preceding options. We’ve regularly updated these release notes with other exciting changes to the beta commands. These changes now apply to their equivalent GA commands. Here’s a recap: * The commands support storing multiple `.gitignore` files in as many places in your packageDirectories as you want. * The `force:source:status` command has a new `--concise` parameter to display terser output. For example, the output doesn't include ignored files. * The `force:source:push|pull` commands are more tolerant when they encounter certain network problems, such as ETIMEDOUT, ECONNRESET, ENOTFOUND and 'socket hang up' errors. The commands now keep trying to connect, at least up to the time specified by the `--wait` parameter. They also display warnings and debugging information so the user knows what's going on. Previously the commands failed on the first connection problem. * The `force:source:push` command uses a new `pushPackageDirectoriesSequentially` option in `sfdx-project.json` to push `packageDirectories` sequentially rather than in one transaction. This change unblocks certain complex deployments. See the [Beta announcement](https://github.com/forcedotcom/cli/issues/1258) for more details and a code example. * The `force:source:push` command has a new `–quiet` parameter that suppresses the displayed list of successfully deployed metadata components. You still see all the error messages, don’t worry. * The commands always check your `.forceignore` file and the package directories configured in your `sfdx-project.json` file and immediately pick up any changes. * We removed the `--all` parameter of `force:source:status`. We also no longer accept the combined use of the `--local` and `--remote` parameters. To view source changes in both your local project and an org, run the command with no parameters. * The `force:source:status` command now displays which changes, if any, are covered by your `.forceignore` file. These changes aren’t included in a push or pull. * One gotcha: Due to changes in the design and performance of the code for deploying and retrieving metadata, the Salesforce CLI-specific hooks have also changed. In particular, we've removed the redundant `postsourceupdate` hook; use `postretrieve` instead. Also, the hook result types have changed. We've updated the [sample repo](https://github.com/salesforcecli/plugin-metadata-hook-demo/blob/master/README.md) with the changes. We're currently updating the [Hooks topic of the Salesforce CLI Plug-In Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins_customize_hooks.htm) with the new information; check back soon for details. We appreciate all your help in testing these beta commands. Thanks a bunch! * NEW: Create a manifest file from all the metadata components in your org with the new `–fromorg` parameter of the `force:source:manifest:create` command. Set the parameter to the username or alias of your org. By default, the command excludes metadata components contained in your org’s packages. To also include these components in your manifest, set the new `–includepackages` parameter to the type of package, either `managed`, `unlocked`, or both. For example, to generate a manifest file that contains all metadata components in an org with alias `my-scratch` and the components defined in all unlocked and managed packages, run this command: `sfdx force:source:manifest:create –fromorg my-scratch –includepackages managed,unlocked` Many thanks to [Jochen Rinder](https://github.com/jayree) who thought of the nifty new feature and then submitted a PR with the code. * FIX: The `force:source:*` commands now support these metadata types: * FlowTest * UiViewDefinition * FIX: The `force:org:beta:create` command correctly sets the new org as your default when you specify the `-s|--setdefaultusername` parameter. (GitHub issue [#1400](https://github.com/forcedotcom/cli/issues/1400)) ## 7.139.0 (Feb 24, 2022) * NEW: We know you love the source-tracking feature of `force:source:push|pull`, and now you can use it with the `force:source:deploy|retrieve|delete` commands too! We've added these Boolean parameters to the three commands: * `--tracksource` : Enable source-tracking for a single command run. * `--forceoverwrite` : Ignore conflict warnings and overwrite source in the org (when deploying) or locally (when retrieving). Think of all the exciting things you can now do: * **Deploy or retrieve only specified changes**. For example, retrieve a single Apex class and update your tracking files rather than having to retrieve _all_ the changes in your org with `force:source:pull`. `sfdx force:source:retrieve -m ApexClass:MyFabClass --tracksource` * **Identify conflicts**. Let's say you want to deploy a single Apex class. If the command detects a conflict with the class in the org, the class isn't deployed and you get a message about the conflict. Then you can decide what to do, such as rerun the command with `--forceoverwrite` to overwrite the class in the org. `sfdx force:source:deploy -m ApexClass:MyFabClass --tracksource --forceoverwrite` * **Repair tracking files**. Let's say you start a deploy, but you lose your internet connection. The deploy eventually completes, but your local source tracking files are now incorrect. What to do? Easy! Run this command to make your local source look like your org and make all your source-tracking files correct again: `sfdx force:source:retrieve -p --tracksource --forceoverwrite` Keep these considerations in mind: * We recommend that you keep using `force:source:push|pull` to sync all changes between your local source and org rather than specific changes. * This new feature doesn't handle deletes. For example, if you delete a metadata component in your org and want to also delete it locally, you must use `force:source:push`. * You can, however, delete local source by specifying the destructive changes parameters (`--postdestructivechanges` and `--predestructivechanges`) of `force:source:delete|deploy`. * **Important**: These new source-tracking flags are compatible only with the source-tracking files associated with the [new `force:source:beta:*` commands](https://github.com/forcedotcom/cli/issues/1258). You can't use these flags with source-tracking files associated with the non-beta commands, such as the current `force:source:push`. * CHANGE: We removed the `force:lightning:lint` command. We deprecated the command on [April 29, 2021](#7990-april-29-2021---salesforcedx-51100). Use the [eslint-plugin-aura npm package](https://github.com/forcedotcom/eslint-plugin-aura) instead. * CHANGE: The `force:org:beta:create` command is more tolerant when it encounters certain network problems, such as ETIMEDOUT, ECONNRESET, ENOTFOUND and 'socket hang up' errors. The command now keeps trying to connect, at least up to the time specified by the `--wait` parameter. It also displays warnings and debugging information so the user knows what's going on. Previously the command failed on the first connection problem. * FIX: The `force:source:beta:push` command now correctly handles failed deployments of `Settings` metadata component types. (GitHub issue [#1401](https://github.com/forcedotcom/cli/issues/1401)) * FIX: The `force:source:beta:push` command correctly handles metadata types that are in folders, such as Document and EmailTemplate. (GitHub issue [#1398](https://github.com/forcedotcom/cli/issues/1398)) * FIX: We've improved the performance of the `force:source:beta:push` command. Special thanks to [mchadwickffdc](https://github.com/mchadwickffdc) and [David Esposito](https://github.com/daveespo) who found the issue and provided excellent data and feedback to help us fix it. Community beta-testing at its best! (GitHub issue [#1394](https://github.com/forcedotcom/cli/issues/1394)) * FIX: We've improved the performance of the `force:source:retrieve` command when deploying StaticResource metadata components. (GitHub issue [#1348](https://github.com/forcedotcom/cli/issues/1348)) ## 7.138.1 (Feb 17, 2022) * CHANGE: Vroom, vroom, the project to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) continues to speed along! This week we moved these commands into the [plugin-community](https://github.com/salesforcecli/plugin-community) plug-in: * `force:community:create` * `force:community:publish` * `force:community:template:list` They all work the same as before. Go build a community. * CHANGE: If you specify an invalid scratch org definition file with the `force:org:beta:create` command, we now display more information in the error to help you troubleshoot the problem. When the beta command becomes generally available, the equivalent GA command `force:org:create` will also display the improved error message. * CHANGE: The `force:source:*` commands display a warning when they find a `.forceignore` file that incorrectly uses the backslash (`\`) as a folder separator. The correct syntax is to use the slash (`/`), same as the [`.gitignore` syntax](https://git-scm.com/docs/gitignore). While we currently accept both separators, we plan to stop supporting the backslash soon. * FIX: FIX: You can now successfully create an unlocked package version. Previously the command failed with an error about an invalid ancestor or an invalid subscriber package version ID. (GitHub issue [#1403](https://github.com/forcedotcom/cli/issues/1403)) * FIX: You can now run the `info:releasenotes:display` command from behind a Web proxy. (GitHub issue [#1378](https://github.com/forcedotcom/cli/issues/1378)) * FIX: The `force:source:*` commands support symlink (symbolic link) source paths. (GitHub issue [#1375](https://github.com/forcedotcom/cli/issues/1375)) * FIX: When you create a user with the `force:user:create` command, Salesforce CLI now uses your MyDomain URL when it authenticates the new user. This change fixes an authentication error when running the command to create an Experience Cloud user on a preview (API version 54.0) scratch org when using JWT. (GitHub issue [#1365](https://github.com/forcedotcom/cli/issues/1365)) * FIX: When you run the `force:data:soql:query` command, and the SOQL query includes a field that contains JSON content, the results now display the actual JSON content. Previously the results would display the unhelpful `[object Object]` text. (GitHub issue [#1318](https://github.com/forcedotcom/cli/issues/1318)) * FIX: The `force:data:record:update` command properly parses JSON content when passed as a field value with the `-v` parameter. (GitHub issue [#72](https://github.com/forcedotcom/cli/issues/72)) ## 7.137.1 (Feb 10, 2022) * NEW: Quickly preview a Visualforce page in your browser by specifying the page to the `force:source:open` command. Visualforce pages have the `.page` suffix. `sfdx force:source:open -f force-app/main/default/pages/StartVFPage.page` Many thanks to [Fodil Boudjedien](https://github.com/fodilo) for designing the new feature and then taking the initiative to submit a PR with the code. It even included tests -- awesome. Keep 'em coming, community! (GitHub issue [#1386](https://github.com/forcedotcom/cli/issues/1386)) * NEW: You're now required to set a package ancestor when you create a 2GP managed package version. To make it easier to increment your package ancestor version number, we added two keywords to the `packageDirectories` section of the `sfdx-project.json` file. We also added a parameter to the `force:package:version:create` command to override this requirement: `--skipancestorcheck`. Get all the details [here](https://help.salesforce.com/s/articleView?id=release-notes.rn_packaging_ancestor_enhancements.htm&type=5&release=236) and [here](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_config_ancestors.htm). * CHANGE: When running `force:package:version:create`, we now correctly fail to create the package version if we detect duplicate package dependencies in the `sfdx-project.json` file. ## 7.136.2 (Feb 3, 2022) * NEW: Get shorter JSON output from running the `force:mdapi:beta:deploy` or `force:mdapi:beta:deploy:report` commands by using the new `--concise` parameter with the `--json` parameter. The new parameter omits success messages from the JSON output. When the two beta commands become generally available, the GA commands, such as `force:mdapi:deploy`, will also have the new parameter. * NEW: When running `force:source:deploy`, specify that deleted components in the destructive changes manifest file are immediately eligible for deletion with the new `--purgeondelete` parameter. By default, deleted components are stored in the Recycle Bin. The `force:mdapi:beta:deploy` command also has this new parameter, and we'll add it to `force:mdapi:deploy` when the beta version becomes generally available. * CHANGE: The [Salesforce CLI open-sourcing train](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) is speeding along and this week we've created the `force:org:beta:create` beta command in the [plugin-org](https://github.com/salesforcecli/plugin-org) plug-in. The command works the same as its equivalent existing one. Try out this beta command before we make the open-source version of `force:org:create` generally available. * CHANGE: We now display a warning message when you run `sfdx update` and haven't yet [uninstalled](https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md#71063-june-17-2021) that pesky `salesforcedx` plug-in. Having it installed can cause unexpected behavior, so we really want it gone. First see if you still have it, and then uninstall it if you do: ```bash sfdx plugins --core sfdx plugins:uninstall salesforcedx sfdx update ``` And pow, all those peculiar CLI issues you had are now solved. (GitHub issue [#1304](https://github.com/forcedotcom/cli/issues/1304)) * FIX: The `auth:accesstoken:store` command uses the correct short parameter name (`-d`) for setting your default Dev Hub org and now matches the other `auth` commands. Thanks to [Matthias Rolke](https://github.com/amtrack) for submitting [the fix](https://github.com/salesforcecli/plugin-auth/pull/359). PRs are even better than issues! * FIX: The `force:source:convert` command works correctly with object translations (CustomObjectTranslation metadata type). (GitHub issue [#1383](https://github.com/forcedotcom/cli/issues/1383)) * FIX: Deploying metadata with the REST API now automatically refreshes your authentication token when necessary. (GitHub issues [#899](https://github.com/forcedotcom/cli/issues/899), [#912](https://github.com/forcedotcom/cli/issues/912)) * FIX: We've updated the full Salesforce CLI Docker image on [Docker Hub](https://hub.docker.com/r/salesforce/salesforcedx/tags?page=1&ordering=last_updated) to use the latest LTS version of Node.js (v16.13.1). * FIX: The `force:source:*` commands now support the EmailTemplateFolder metadata type. (GitHub issue [#1345](https://github.com/forcedotcom/cli/issues/1345)) ## 7.135.0 (Jan 27, 2022) * CHANGE: Have we mentioned that we're [open-sourcing Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021)? This week we moved the `force:source:ignored:list` command into the [plugin-source](https://github.com/salesforcecli/plugin-source) plug-in. It works the same as before. * FIX: The `force:source:pull` and `force:source:retrieve` commands correctly retrieve and merge the CustomLabels metadata type. (GitHub issue [#1317](https://github.com/forcedotcom/cli/issues/1317)) * FIX: The `force:source:beta:*` commands support storing multiple `.gitignore` files in as many places in your `packageDirectories` as you want. Previously, the `.gitignore` files would affect source tracking and sometimes result in unexpected behavior. (GitHub issue [#1335](https://github.com/forcedotcom/cli/issues/1335)) ## 7.134.0 (Jan 20, 2022) * NEW: Display terser output by running the `force:source:beta:status` command with the new `--concise` parameter. For example, the output doesn't include ignored files. (GitHub issue [#1312](https://github.com/forcedotcom/cli/issues/1312)) * CHANGE: The project to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021) is chugging along smoothly, and this week we've created these beta commands in the [plugin-source](https://github.com/salesforcecli/plugin-source) plug-in: * `force:mdapi:beta:retrieve` * `force:mdapi:beta:retrieve:report` We also improved the commands by adding these two parameters to each one: * `--unzip`: Automatically extract files from the retrieved `.zip` file * `--zipfilename`: Specify a name for the retrieved `.zip` file Other than these new parameters, the commands work the same as their equivalent existing ones. Try out these beta commands before we make the open-source versions of `force:mdapi:retrieve` and `force:mdapi:retrieve:report` generally available. * FIX: We've improved how the `force:source:beta:*` commands match package name directories. Previously, for example, `force:source:beta:deploy` deployed metadata in a directory that wasn't defined in `sfdx-project.json` if its name started with the same string as a legitimate package directory, such as `force-app-extra` and `force-app`. (GitHub issue [#1336](https://github.com/forcedotcom/cli/issues/1336)) * FIX: The `force:project:create` command creates a `sfdx-project.json` file with the correct `sourceApiVersion` (53.0). (GitHub issue [#1278](https://github.com/forcedotcom/cli/issues/1278)) ## 7.133.0 (Jan 13, 2022) Happy new year, Salesforce CLI community! * NEW: We're pretty proud and excited about the new features and fixes we release in Salesforce CLI each week. And we want you to know about them! So when you run `sfdx update`, we now automatically display the release notes for the version you're updating to. Under the covers, the update is simply running the [info:releasenotes:display](https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md#71301-dec-9-2021) (alias `whatsnew`) command, which you can run anytime to read the release notes again. Which I'm sure you're eager to do. Configure this feature with these environment variables: * `SFDX_HIDE_RELEASE_NOTES`: Set to `true` to silence the automatic display of the release notes when you run sfdx update. Default value is `false`. * `SFDX_HIDE_RELEASE_NOTES_FOOTER`: Set to `true` to stop displaying the boilerplate footer. Default value is `false`. * CHANGE: We continue on our journey of [open-sourcing Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021), and this week we've created these beta commands in the [plugin-source](https://github.com/salesforcecli/plugin-source) plug-in: * `force:mdapi:beta:deploy` * `force:mdapi:beta:deploy:report` Both beta commands work the same as their equivalent existing commands. Try out these beta commands before we make the open-source versions of `force:mdapi:deploy` and `force:mdapi:deploy:report` generally available. * CHANGE: If the `info:releasenotes:display` command can't find an exact match of the installed CLI version in the release notes, the command displays the notes for the closest version. The command behaves the same way if it can't find the exact version specified by the `–version` parameter in the release notes. * FIX: We've changed the polling frequency of the `force:source` commands based on the size of the deployment. In general, we poll more frequently when the deployment is small and less frequently when it's large. This new behavior results in quicker-feeling smaller deployments, and reduces the API requests, and thus network traffic, for large deployments. * FIX: We've improved the error message when Salesforce CLI encounters invalid XML, such as a badly formed metadata source file during a deployment. (GitHub issue [#1261](https://github.com/forcedotcom/cli/issues/1261)) * FIX: The command `force:source:retrieve -m CustomFieldTranslation` correctly retrieves the field translation source files, even if there's no parent CustomObjectTranslation in the org. In this case, the command generates an empty CustomObjectTranslation source file. Previously the command retrieved only the CustomFieldTranslation source files, which are invalid by themselves without a CustomObjectTranslation parent file. (GitHub issues [#1233](https://github.com/forcedotcom/cli/issues/1233), [#1241](https://github.com/forcedotcom/cli/issues/1241), [#1262](https://github.com/forcedotcom/cli/issues/1262)) * FIX: If you run the `force:data:record:update` command but submit invalid data that violates a validation rule, the command now returns the actual validation error from the org. (GitHub issue [#1327](https://github.com/forcedotcom/cli/issues/1327)) * FIX: We've improved the error message when the command `force:org:create` is unable to reset the source tracking after creating the scratch org and deploying the settings. (GitHub issue [#1337](https://github.com/forcedotcom/cli/issues/1337)) ## 7.132.0 (Dec 23, 2021) NOTE: Because of the holidays, we're not publishing a new `stable-rc` release today or next week (Dec 30, 2021). We'll return to our regular weekly release schedule on Jan 6, 2022. (Yikes, it's almost 2022. How did that happen?) We hope you have a joyful and peaceful holiday season, and see you in the new year! * CHANGE: The `force:source:deploy|retrieve|convert` and `force:source:beta:push|pull` commands are more tolerant when they encounter certain network problems, such as ETIMEDOUT, ECONNRESET, ENOTFOUND and 'socket hang up' errors. The commands now keep trying to connect, at least up to the time specified by the `--wait` parameter. They also display warnings and debugging information so the user knows what's going on. Previously the commands failed on the first connection problem. (GitHub issues [#529](https://github.com/forcedotcom/cli/issues/529), [#1007](https://github.com/forcedotcom/cli/issues/1007), [#1301](https://github.com/forcedotcom/cli/issues/1301)) * FIX: The `force:org:create` command no longer returns the error `ERROR running force:org:create: Unrecognized option: cookiesAllowAllPaths`. This error occurred only on npm-based installations of Salesforce CLI running version 7.120.0 or earlier. (GitHub issue [#1323](https://github.com/forcedotcom/cli/issues/1323)) * FIX: The command `force:data:soql:query` correctly runs SOQL queries that use the `count()` aggregate function without a field name, such as `SELECT COUNT() FROM Account WHERE Name LIKE 'a%'`. Previously the command showed 0 records returned and displayed the erroneous `Warning: The query result is missing YY records due to a ZZ record limit.` (GitHub issue [#1320](https://github.com/forcedotcom/cli/issues/1320)) ## 7.131.0 (Dec 16, 2021) * CHANGE: Installing the `sfdx` executable with the `npm install sfdx-cli -g` command no longer installs the `@salesforce/cli` package, which corresponds to the `sf` executable. To install `sf` via npm, run this command: `npm install @salesforce/cli -g`. Installing Salesforce CLI with the installers and TAR files hasn't changed; they still install both the `sfdx` and `sf` executables. ## 7.130.1 (Dec 9, 2021) * NEW: Assign permission set licenses to users with the new `force:user:permsetlicense:assign` command. The command works similarly to the existing `force:user:permset:assign` command. This example shows how to assign the permission set license named `DreamHouse` to a user with username `me@my.org`: ```bash sfdx force:user:permsetlicense:assign -n DreamHouse -u me@my.org ``` * NEW: Quickly catch up on the new and changed features in any Salesforce CLI release with the new `info:releasenotes:display` command (alias `whatsnew`). By default, the command displays the release notes for the Salesforce CLI version that's currently installed. Use the `--version|-v` parameter to specify a specific CLI version or a tag, such as `stable-rc`. For example: ```bash sfdx whatsnew sfdx whatsnew --version stable-rc sfdx whatsnew -v 7.127.0 ``` * NEW: Find out who created a package, package version, or package version creation request with the updated output of the following commands, which now includes a `Created By` property: * `force:package:list --verbose` * `force:package:version:list --verbose` * `force:package:version:report` * `force:package:version:create:list` * `force:package:version:create:report` * NEW: The `force:source:beta:push` command uses a new `pushPackageDirectoriesSequentially` option in `sfdx-project.json` to push packageDirectories sequentially rather than in one transaction. This should unblock certain complex deployments. See the [Beta announcement](https://github.com/forcedotcom/cli/issues/1258) for more details and a code example. (GitHub issue [#1269](https://github.com/forcedotcom/cli/issues/1269)) * CHANGE: For security reasons, we no longer display the URL by default in the terminal or command window when you run `force:org:open`. We continue to display the URL when you specify either the `--urlonly` or `--json` parameters, but we also show a security warning about displaying sensitive information. * CHANGE: We continue to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021), and this week we moved the `force:org:delete` command into the [plugin-org](https://github.com/salesforcecli/plugin-org) plug-in. The command works the same as before. * FIX: We updated the `--help` of the `auth:sfdxurl:store` command to better explain the format of the SFDX auth URL. We also added that you can't obtain the URL from `force:org:display` if you authorized the org using the JWT bearer flow. (GitHub issues [#1297](https://github.com/forcedotcom/cli/issues/1297) and [#1298](https://github.com/forcedotcom/cli/issues/1298)). * FIX: The `force:mdapi:listmetadata -m MDType` command correctly returns properties of metadata components. Previously it returned the error `No metadata for type: MDType`. (GitHub issue [#1285](https://github.com/forcedotcom/cli/issues/1285)) * FIX: Successfully ignore children of decomposed metadata types when you deploy or retrieve by adding the children to the `.forceignore` file. For example, if you add `**/Account/listViews/**` to your `.forceignore` file and then run `force:source:retrieve -m CustomObject:Account`, the command doesn't retrieve any list views for the Account object. Previously the command would incorrectly retrieve them. (GitHub issue [#938](https://github.com/forcedotcom/cli/issues/938)) ## 7.129.0 (Dec 2, 2021) * NOTE: Because of the Thanksgiving holiday, we didn't publish a release candidate last Thursday. As a result, this week's `stable` release is the same as last week's (Nov 25, 2021). * CHANGE: We continue to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021), and this week we've moved these commands into the [plugin-source](https://github.com/salesforcecli/plugin-source) plug-in: * `force:mdapi:deploy:cancel`: Works the same as before. * `force:mdapi:beta:convert`: This command is the beta version of `force:mdapi:convert`. We've improved the performance and added a spinner that shows the progress of the conversion. Try out the beta version before we move the `force:mdapi:convert` command into plugin-source and make it generally available. ## 7.127.0 (Nov 18, 2021) * CHANGE: We continue to [open-source Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021), and this week we've moved the `force:mdapi:listmetadata` and `force:mdapi:describemetadata` commands into the [plugin-source](https://github.com/salesforcecli/plugin-source) plug-in. The commands work the same as before, except for an improvement in the JSON output. Previously, if you ran `force:mdapi:describemetadata` with both `--resultfile` and `--json` parameters, the `message` property of the JSON output included only the name of the result file. We now include the actual information that's in the result file. We made a similar change to `force:mdapi:listmetadata`, where we also made the JSON output consistent regardless of the number of returned metadata properties. Previously, the JSON output was different depending on the number of returned properties. ## 7.126.0 (Nov 11, 2021) * CHANGE: We're deprecating the `--all` parameter of `force:source:status`. We're also deprecating the combined use of the `--local` and `--remote` parameters. To view source changes in both your local project and an org, run the command with no parameters. * FIX: The `force:source:deploy|retrieve|convert` commands are smarter about classifying metadata. Previously, for example, the commands naively classified the metadata file `classes/foo/objects/myClass.cls` as a CustomObject simply because the word `objects` was in the directory path. The commands now determine the actual metadata type, such as an ApexClass. * FIX: We've improved Salesforce CLI's internal metadata registry so it better handles the Workflow and SharingRules metadata types. Thank you, [Jochen Rinder](https://github.com/jayree), for contributing the code for this fix. We love that you, and our awesome community, take the time and initiative to improve the CLI. It keeps us on our toes too. Keep those contributions coming! * FIX: We fixed a bug where the CLI confused SiteDotCom and CustomSite and would fail with `Expected source files for type 'SiteDotCom'` ## 7.125.0 (Nov 4, 2021) * NEW: We've greatly improved the source tracking commands, and we'd love you to try out the beta versions before we make them generally available. We're doing something different this time: rather than provide the beta commands in a separate plug-in, we're including them right in this release. The beta command names are similar to the existing ones, but are in the `force:source:beta` topic: * `force:source:beta:pull` * `force:source:beta:push` * `force:source:beta:status` * `force:source:beta:tracking:clear` * `force:source:beta:tracking:reset` The existing commands, such as `force:source:pull`, continue to work as before. Check out [Source Tracking Beta](https://github.com/forcedotcom/cli/issues/1258) for additional details and gotchas. * NEW: Specify the browser to use with the `force:org:open` command with the new `--browser|-b` parameter. Supported browsers are `chrome`, `edge`, and `firefox`. If you don't specify `--browser`, the org opens in your default browser. For example, to open an org in Firefox: `sfdx force:org:open --browser firefox` Thank you, [Todd Halfpenny](https://github.com/toddhalfpenny), for [requesting the nifty new feature](https://github.com/forcedotcom/cli/issues/1015), and then taking the initiative and contributing the code yourself. We love contributions from the community, and look forward to many more! * FIX: We fixed a bug that prevented `sfdx update` from also updating `sf` to its latest version. * FIX: The `force:source:retrieve` command correctly retrieves CustomObjectTranslation metadata types into new projects. Previously you'd get the error `ERROR running force:source:retrieve: Metadata API request failed: Component conversion failed`. ([GitHub issue #1233](https://github.com/forcedotcom/cli/issues/1233)) * FIX: We restarted publishing the full versions of the Salesforce CLI Docker container images on [Docker Hub](https://hub.docker.com/r/salesforce/salesforcedx/tags?page=1&ordering=last_updated). ([GitHub issue #1249](https://github.com/forcedotcom/cli/issues/1249)) ## 7.124.0 (Oct 28, 2021) * NEW: Delete metadata components in your org at the same time you run `force:source:deploy --manifest` with the new `--predestructivechanges` and `--postdestructivechanges` parameters. Similar to how the `--manifest` parameter works, set the new parameters to a manifest file. But rather than deploy the components in the file, the command deletes them from your org. Depending on the parameter, the delete executes either before (`pre`) or after (`post`) the deploy. For example, this command deletes the components in the `preDestruct.xml` manifest file before you deploy the components in the `package.xml` file: `sfdx force:source:deploy --manifest package.xml --predestructivechanges preDestruct.xml` Don't have a manifest file handy? No problem, run the `force:source:manifest:create` command to create one! This example shows how to create a file that you can use to delete the `NoLongerNeededClass` Apex class: `sfdx force:source:manifest:create -m ApexClass:NoLongerNeededClass --manifestname preDestruct.xml` See [Deleting Components from an Org](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_deleting_files.htm) in the Metadata API Developer Guide for more information about using destructive change manifest files. ## 7.123.0 (Oct 21, 2021) * FIX: The `force:source:deploy|retrieve|convert|delete` commands support the `EclairGeoData` metadata type again. * FIX: The `force:org:display --json` command displays in the JSON output the security warning about exposing sensitive information, consistent with the other commands. ([GitHub issue #1229](https://github.com/forcedotcom/cli/issues/1229)) * FIX: The `force:org:open` command correctly opens sandboxes in the `.mil` domain. Previously the command tried to open a different domain. ## 7.122.1 (Oct 14, 2021) * NEW: The `force:source:deploy|retrieve|convert|delete` commands support these Slack-related metadata types that are new in the Winter '22 Salesforce release: `ViewDefinition` and `SlackApp`. * FIX: The `force:source:deploy|retrieve|convert|delete` commands support the `SharingGuestRule` metadata type again. ([GitHub issue #1199](https://github.com/forcedotcom/cli/issues/1199)) * FIX: The `force:source:delete` command no longer fails when you try to delete metadata types that are in the org, but not in your local project directory. Previously you'd get the error `Entity of type MD-Type named MD-Type-Name cannot be found`. ([GitHub issue #1203](https://github.com/forcedotcom/cli/issues/1203)) ## 7.121.8 (Oct 7, 2021) * CHANGE: As we announced on [March 18, 2021](./README.md#5140-march-18-2021---cli-7920), the `--json` output of the `force:org:list` command no longer returns the property `connectedStatus` for scratch orgs. We've also removed the warning. * FIX: When you delete a scratch org with the `force:org:delete` command, we now ensure that the associated Dev Hub org always deletes the corresponding record from the ActiveScratchOrg object. Previously, in certain circumstances, the record wasn't deleted, which could cause you to incorrectly exceed over your scratch org limit. ([GitHub issue #1155](https://github.com/forcedotcom/cli/issues/1155)) * FIX: The `force:source:convert` command correctly converts the `CustomFieldTranslation` metadata type. ## 7.120.0 (Sept 30, 2021) * NEW: Some commands (`force:org:open`, `force:org:display`, `force:user:display`, `force:source:open`) display tokens and URLs with tokens embedded in them. They now include a warning about the risks of sharing that sensitive information. * NEW: We've added a warning and additional information to explain why the command `force:source:retrieve -m CustomField` succeeds but returns no results, even when your org contains custom fields. This behavior is expected because the Metadata API never returns results if you retrieve the `CustomField` type on its own without also retrieving `CustomObject`. If you want to retrieve all your custom fields, try this command instead: `force:source:retrieve -m CustomField,CustomObject`. You get the same behavior if you run `force:source:retrieve -x manifest` and your manifest file contains a `CustomField` entry with an `*` to retrieve all custom fields, but no `CustomObject` entry. Check out the new warning for hints to actually retrieve your custom fields. * NEW: Specify the level of deployment tests to run when you delete metadata source files with the new `--testlevel` parameter of `force:source:delete`. The new parameter works the same as the `--testlevel` parameter of `force:source:deploy`, although the list of valid values is shorter: `NoTestRun`, `RunLocalTests`, and `RunAllTestsInOrg`. See the [CLI Reference guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_source.htm#cli_reference_force_source_deploy) for more information about each value. For example, to run all org tests when you delete the MyMetadataType type from both your local project and the org, run this command: `sfdx force:source:delete --metadata MyMetadataType --testlevel RunAllTestsInOrg` As a result of this new feature, [GitHub issue #971](https://github.com/forcedotcom/cli/issues/971) is fixed. * CHANGE: As we [warned last year](./v50.md#5020-october-22-2020---cli-7771), the `force:source:*` commands no longer support the old format of the `.forceignore` file. When parsing the `.forceignore` file, the commands now always use the same rules and patterns as [git uses with the `.gitignore` file](https://git-scm.com/docs/gitignore). * FIX: The `force:source:deploy|retrieve|convert` commands now support the Reports, Dashboards, Documents, and EmailTemplates metadata types when they're nested in directories of more than one level. (GitHub issues [#1112](https://github.com/forcedotcom/cli/issues/1112) and [#1173](https://github.com/forcedotcom/cli/issues/1173)) * FIX: The `force:source:deploy` command provides more failure details in situations where it previously reported the un-helpful `Deploy Failed` * FIX: The `force:org:create` command now uses only polling, and not the Streaming API, to listen for updates about the scratch org creation. As a result, you no longer get the error `Socket timeout occurred while listening for results` if the scratch org creation takes a long time. ([GitHub issue #1149](https://github.com/forcedotcom/cli/issues/1149)) ## 7.119.2 (Sept 24, 2021) * FIX: The `force:mdapi:deploy:cancel` command no longer fails with the error `TypeError: MdapiCancelCommandImpl is not a constructor`. * FIX: The `force:source:deploy|retrieve|convert` commands now support the ManagedTopics metadata type. ([GitHub issue #1192](https://github.com/forcedotcom/cli/issues/1192)) * FIX: The `force:source:deploy|retrieve|convert` commands now support the Reports, Dashboards, Documents, and EmailTemplates metadata types. Note that these types don't yet work when nested in directories more than one level. We're working on the fix. (GitHub issues [#1165](https://github.com/forcedotcom/cli/issues/1165) and [#1180](https://github.com/forcedotcom/cli/issues/1180)) * FIX: `plugins:install` no longer fails for Windows users (Github issue [#1198](https://github.com/forcedotcom/cli/issues/1198)) as part of the change to support plugins in private npm packages and private registries. ## 7.118.1 (Sept 16, 2021) * FIX: The `force:source:deploy|retrieve|convert` commands now support the SharingCriteriaRule, SharingOwnerRule, AutoResponseRule, and AssignmentRule metadata types. ([GitHub issue #833](https://github.com/forcedotcom/cli/issues/833)) ## 7.117.0 (Sept 9, 2021) * FIX: The `force:source:deploy|retrieve|convert` commands now support the RestrictionRule metadata type. ([GitHub issue #1158](https://github.com/forcedotcom/cli/issues/1158)) * FIX: As a result of a recent Salesforce CLI bug fix, the `force:source:deploy|retrieve|convert` commands incorrectly started including the CustomFieldTranslation metadata type in the manifest when handling CustomObjectTranslation types. Because the Metadata API doesn't support CustomFieldTranslation, deploys and retrieves resulted in the error `Unknown type name 'CustomFieldTranslation' specified in package.xml` The commands no longer include the CustomFieldTranslation type in the manifest. (GitHub issues [1135](https://github.com/forcedotcom/cli/issues/1135) and [1161](https://github.com/forcedotcom/cli/issues/1161)) * FIX: We’ve improved the error when the `force:source:deploy|retrieve|convert` commands encounter an Aura metadata type, such as AuraDefinitionBundle, within a custom object folder in your project. The new error (`Unexpected child metadata [/path/to/child/metadata] found for parent type [Parent]`) provides more information about the problem than the old error (`ERROR running force:source:retrieve: Cannot read property 'id' of undefined`). ([GitHub issue #1148](https://github.com/forcedotcom/cli/issues/1148)) * FIX: The command `force:org:create` successfully creates a scratch org when `sfdx-project.json` configures [package ancestors](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_config_ancestors.htm). ## 7.116.2 (Sep 2, 2021) * FIX: When running `force:source:deploy -m`, you can now include a space when specifying the metadata type, as long as you enclose the parameter value in double quotes. Previously, including a space, such as `-m "ApexClass: MyClass"` returned the error `No source backed components present in the package.` ([GitHub issue #1151](https://github.com/forcedotcom/cli/issues/1151)) * FIX: The `force:source:*` commands now support the InboundCertificate metadata type. ([GitHub issue #995](https://github.com/forcedotcom/cli/issues/995)) * FIX: The `force:source:deploy` command correctly deploys the IndustriesManufacturingSettings metadata type. Previously it returned the error `Unknown type name 'IndustriesManufacturingSettings' specified in package.xml`. ([GitHub issue #866](https://github.com/forcedotcom/cli/issues/866)) * FIX: The `force:source:convert` command now includes child elements in the `package.xml` manifest file, such as custom fields of a custom object. Previously the command didn't include them in the manifest, which caused deployments to packaging orgs to fail with an error such as `UNKNOWN_EXCEPTION: Unable to handle . filepath not expected`. ([GitHub issue #1115](https://github.com/forcedotcom/cli/issues/1115)) * FIX: The `force:source:deploy|retrieve|convert` commands support the Territory2 metadata types. ([GitHub issue #1147](https://github.com/forcedotcom/cli/issues/1147)) ## 7.115.1 (Aug 26, 2021) * NEW: Check out the new `sf` CLI! Update `sfdx` to this week's release and you automatically get the beta version of `sf`. ```bash $ sfdx update $ sf help ``` Read the [Getting Started guide](https://github.com/salesforcecli/cli/wiki), give the commands a try, and let us know what you think. * FIX: The `force:source:*` commands correctly deploy, retrieve, and convert big object indexes. ([GitHub issue #1141](https://github.com/forcedotcom/cli/issues/1141)) * FIX: The `force:source:deploy` command correctly deploys a custom label. Previously it failed with the error `Not in package.xml`. ([GitHub issue #1133](https://github.com/forcedotcom/cli/issues/1133)) * FIX: The `force:source:deploy` command correctly deploys custom objects that use field history tracking. Previously it failed with the error `Component conversion failed: group.push is not a function`. ([GitHub issue #1119](https://github.com/forcedotcom/cli/issues/1119)) * FIX: We’ve improved the error when the `force:source:*` commands encounter an unexpected metadata child type, such as an Apex class within a custom object. The new error (`Unexpected child metadata [/path/to/child/metadata] found for parent type [Parent]`) provides more information about the problem than the old error (`TypeError: Cannot set property 'content' of undefined at DecomposedSourceAdapter.populate`). ([GitHub issue #1106](https://github.com/forcedotcom/cli/issues/1106)) * FIX: The command `force:org:list --json` consistently includes namespace prefixes for scratch orgs that have them. ([GitHub issue #1146](https://github.com/forcedotcom/cli/issues/1146)) ## 7.114.0 (Aug 19, 2021) * NEW: Create a project manifest that lists the metadata components you want to deploy, retrieve, or delete with the new `force:source:manifest:create` command. Use the `--sourcepath` or `--metadata` parameters to specify the source files or metadata components to include in the manifest. Use the `--manifesttype` parameter to create a specific type of manifest with a prescribed name, such as the default `package.xml` or one that adds or deletes components, such as `destructiveChangesPost.xml`. Here are the valid parameter values and the corresponding created filenames: * `package` : `package.xml` (default) * `pre` : `destructiveChangesPre.xml` * `post` : `destructiveChangesPost.xml` * `destroy` : `destructiveChanges.xml` Alternatively, use the `--manifestname` parameter to create a manifest with a custom name. See the Metadata API Developer Guide for information about the [package.xml manifest file](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy.htm) and the [destructive changes manifest files](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_deleting_files.htm). This example creates a default `package.xml` file that contains all the Apex classes in your project: ```sfdx force:source:manifest:create -m ApexClass``` This example creates a `destructiveChanges.xml` manifest file that contains the `MyApexClass` metadata component: ```sfdx force:source:manifest:create --metadata ApexClass:MyApexClass --manifesttype destroy``` This example creates a custom file called `myNewManifest.xml` that contains all the source in the `force-app` directory: ```sfdx force:source:manifest:create --sourcepath force-app --manifestname myNewManifest``` * CHANGE: We no longer publish Docker container images called `salesforce/salesforcedx:latest` on Docker Hub. Instead we publish two flavors of the Salesforce CLI release and release candidate: slim and full. For example, to pull the slim version of the latest Salesforce CLI, run: ```docker pull salesforce/salesforcedx:latest-slim``` See [Run Salesforce CLI Using a Docker Image](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_docker.htm) for more information. * FIX: The `force:source:convert --packagename --outputdir ` now works almost the same as before we broke out the deploy-retrieve code into its [own plug-in](https://github.com/salesforcecli/plugin-source). For a brief period, the command incorrectly created a `` subdirectory under the output directory; now it correctly stores the converted files in the output directory as before. However, due to another bug, custom fields, list views, record types, compact layouts, and other metadata components aren't included in the `package.xml`. The fix will be available as soon as possible. ([GitHub issue #1115](https://github.com/forcedotcom/cli/issues/1115)) * FIX: Static resource compression when deploying with `force:source:deploy` now works the same as before we broke out the deploy-retrieve code into its [own plug-in](https://github.com/salesforcecli/plugin-source). For a brief period, the compression algorithm changed, which resulted in large static resources close to the 5-MB limit no longer deploying. ([GitHub issue #1098](https://github.com/forcedotcom/cli/issues/1098)) ## 7.113.0 (August 12, 2021) * FIX: We fixed some under-the-hood bugs. ## 7.112.0 (August 4, 2021) * NEW: We [announced it back in June](https://github.com/forcedotcom/cli/issues/1057), and now it's a reality: we've greatly improved the performance and reliability of these commands: * `force:source:convert` * `force:source:deploy` * `force:source:deploy:cancel` * `force:source:deploy:report` * `force:source:open` * `force:source:retrieve` Want to see what we did? We created a [new plug-in](https://github.com/salesforcecli/plugin-source) that's bundled with Salesforce CLI. The deploy-retrieve code itself is [here](https://github.com/forcedotcom/source-deploy-retrieve). Go ahead, give the updated commands a try; they work so fast, you can now leave work a little early and go surfing. Or bake banana bread. Or take a nap. The possibilities are endless. But there's more! We also added these new parameters: * `force:source:deploy:report --verbose` * `force:source:deploy --soapdeploy` One gotcha: Due to changes in the design and performance of the core code, the Salesforce CLI-specific hooks aren't backwards compatible. For example, the `postretrieve` hook replaces the `postsourceupdate` hook for retrieves, and the hook result types have changed. We're updating the [Hooks topic of the Salesforce CLI Plug-In Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins_customize_hooks_list.htm) with all the new information; check back soon for details. * NEW: Increase the strength of the password generated by the `force:user:password:generate` command with the `--complexity|-c` and `--length|-l` parameters. Set the `--complexity` parameter to an integer between 0 and 5 to specify the set of characters used in the generated password: * 0 - lower case letters only * 1 - lower case letters and numbers only * 2 - lower case letters and symbols only * 3 - lower and upper case letters and numbers only * 4 - lower and upper case letters and symbols only * 5 - lower and upper case letters and numbers and symbols (default) Set the `--length` parameter to specify the number of characters in the password. Valid values are between 8 and 1000, default value is 13. For example, to generate a password with complexity 4 and length 15 for your default username: `sfdx force:user:password:generate --complexity 4 --length 15` * FIX: The command `force:org:open --urlonly --json` no longer prints the error `JsonParseError: Unexpected end of JSON input` after the JSON output when you've also set the SFDX_LOG_LEVEL environment variable to `debug`. ([GitHub sfdx-core repo, issue #153](https://github.com/forcedotcom/sfdx-core/issues/153)) * FIX: When the `force:org:create` command finishes executing, the command cleans up after itself by removing the temporary folder it created called `shape`, including if the command fails. The command also uses a separate and uniquely named temporary folder for each execution; the folder is called `shape_`, such as `shape_1628100694156`. Previously, the command didn't remove the folder, which sometimes interfered with subsequent scratch org creates. If you want the folder to remain after the command finishes, set the SFDX_MDAPI_TEMP_DIR environment variable to the root folder where you want the `shape_` to live. ## July 29, 2021 * We aren't releasing a Salesforce CLI patch this week. The latest version of Salesforce CLI remains 7.110.0. ## July 22, 2021 * We aren't releasing a Salesforce CLI patch this week. The latest version of Salesforce CLI remains 7.110.0. ## 7.110.0 (July 15, 2021) * NEW: The `force:source:*` commands support these metadata types: * ConnectedSystem * DataMappingSchema * DataMapping * FederationDataMappingUsage * WaveComponent ## 7.109.0 (July 8, 2021) * FIX: We fixed some under-the-hood bugs. ## 7.108.0 (July 1, 2021) * NEW: Run Salesforce CLI using Docker container images that we publish on [Docker Hub](https://hub.docker.com/r/salesforce/salesforcedx). We follow the same release process as our installers and npm packages. Each week we publish a Docker container image for that week’s release candidate (`latest-rc`). The following week we retag the image as `latest`. You can run the `latest` or `latest-rc` CLI versions, or a specific numbered version. For each version we provide two flavors: * **slim**: Just the CLI installed on Linux plus OpenJDK 11. * **full**: The CLI installed with npm on a full Node.js installation, plus OpenJDK 11 and additional utilities such as jq. Use [this Web page](https://hub.docker.com/r/salesforce/salesforcedx/tags?page=1&ordering=last_updated) or this table to determine the name of the image you want to use. |CLI Version Type|Docker Hub Image Name| |-------------------------------------|------------------------------------| |Slim latest release|`salesforce/salesforcedx:latest-slim`| |Full latest release|`salesforce/salesforcedx:latest-full`| |Slim release candidate|`salesforce/salesforcedx:latest-rc-slim`| |Full release candidate|`salesforce/salesforcedx:latest-rc-full`| |Slim specific version, such as 7.107.0|`salesforce/salesforcedx:7.107.0-slim`| |Full specific version, such as 7.107.0|`salesforce/salesforcedx:7.107.0-full`| For example, to pull and run the slim CLI release candidate image: ```bash docker pull salesforce/salesforcedx:latest-rc-slim docker run -it salesforce/salesforcedx:latest-rc-slim ``` Then you can run Salesforce CLI commands, such as: `sfdx version` To exit the Salesforce CLI Docker container: `exit` You can also remotely execute commands from outside the container once you have it running and know the container ID: ```bash docker exec -it 8b1e2696a243 bin/bash sfdx version ``` * NEW: Get detailed CLI version information in JSON format with just a single command. Use the new `--json` parameter of `sfdx version` to get JSON output. Use the new `--verbose` parameter to get detailed information, such as the full list of installed plug-ins. Use them together to easily gather your environment details for us when you report an issue: `sfdx version --json --verbose` * NEW: Authorize an org using an existing Salesforce access token with the new `auth:accesstoken:store` command. You're required to use the `--instanceurl` parameter to specify the instance that hosts your org. By default, the command runs interactively and asks you for the access token. If you've previously authorized the org, the command prompts whether you want to overwrite the local authentication file. Specify the `--noprompt` parameter to not be prompted about this overwrite. To use the command in a CI/CD script, set the new SFDX_ACCESS_TOKEN environment variable to the access token. Then run the command with the `--noprompt` parameter. For example, if your access token is `00D1234!XYZ` (usually much longer!): ```bash export SFDX_ACCESS_TOKEN='00D1234!XYZ' sfdx auth:accesstoken:store --instanceurl https://mycompany.my.salesforce.com --noprompt ``` ## 7.107.0 (June 24, 2021) * FIX: Salesforce CLI honors the `instanceUrl` config value and corresponding `SFDX_INSTANCE_URL` environment variable when the `sfdx-project.json` file doesn't contain the `sfdcLoginUrl` property. Previously the CLI ignored them and instead used the default value of `sfdcLoginUrl` (https://login.salesforce.com). ([GitHub issue #616](https://github.com/forcedotcom/cli/issues/616)) * FIX: Let's say you log in to an org with `auth:web:login` and set an alias, and then rerun the same command with the same username but set a different alias. The `force:org:list|display` commands show the most recent alias for that username. Previously the commands continued to display the first alias. ([GitHub issue #1031](https://github.com/forcedotcom/cli/issues/1031)) ## 7.106.3 (June 17, 2021) * NEW: We've removed the `salesforcedx` plug-in from Salesforce CLI. Don't worry, we haven't removed any functionality. The `salesforcedx` plug-in never did much; it simply aggregated other ones that contain the commands to create scratch orgs, deploy source, and so on. The CLI itself (`sfdx-cli`) is already an aggregator plug-in. We [announced this change](https://github.com/forcedotcom/cli/issues/1016) a month ago. If you didn't follow the steps to prepare, do them now: - If you previously installed a tagged version of `salesforcedx` with the `sfdx plugins:install` command, uninstall it: `sfdx plugins:uninstall salesforcedx` - Update the CLI as usual: `sfdx update` - Remove the `sfdx plugins:install salesforcedx` command from your scripts. Going forward, don't manually install the `salesforcedx` plug-in. If you do you'll no longer automatically get the latest versions of the other plug-ins. We know there are still ways to install it, but just don't. Really. As of June 16, 2021, all orgs have been updated to the Summer '21 release (API Version 52.0). Most CLI commands also default to 52.0. But if you find a command that hasn't yet been updated, set the `apiVersion` config value. `sfdx config:set apiVersion=52.0 --global` Finally, as a result of removing the `salesforcedx` plug-in, we've also simplified how we version Salesforce CLI. Starting today, the CLI's version reflects the version of the `sfdx-cli` plug-in (such as 7.106.3). Previously we also referenced the `salesforcedx` plug-in version (such as 51.16.0), which was a tad confusing. Your work life just got a tiny bit easier. How great is that? ## 7.105.0 (June 10, 2021) - (salesforcedx 51.16.0) * FIX: We fixed some under-the-hood bugs. ## 7.104.0 (June 3, 2021) - (salesforcedx 51.15.0) * FIX: We fixed some under-the-hood bugs. ## 7.103.0 (May 27, 2021) - (salesforcedx 51.14.0) * NEW: We recommend that you always use the latest version or release candidate of Salesforce CLI. However, if you absolutely _must_ install an older version, we still have your back! We now publish JSON files that list the URLs to download recent versions of the installers and TAR files for each supported operating system. Each week we'll add the latest released version; versions will remain on the list for 20 weeks. We'll keep the TAR and installer files themselves for 40 weeks minimum. **NOTE**: We continue to keep all old versions of the [sfdx-cli npm package](https://www.npmjs.com/package/sfdx-cli). |Operating System| File Type|TAR Compression Type | Link to JSON File| |----------------|-----------------------|------------------------|---------------------| |Linux ARM |TAR |gz |[sfdx-linux-arm-tar-gz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-linux-arm-tar-gz.json)| |Linux ARM |TAR |xz |[sfdx-linux-arm-tar-xz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-linux-arm-tar-xz.json)| |Linux 64 |TAR |gz |[sfdx-linux-x64-tar-gz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-linux-x64-tar-gz.json)| |Linux 64 |TAR |xz |[sfdx-linux-x64-tar-xz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-linux-x64-tar-xz.json)| |Windows 64 |TAR |gz |[sfdx-win32-x64-tar-gz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-win32-x64-tar-gz.json)| |Windows 64 |TAR |xz |[sfdx-win32-x64-tar-xz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-win32-x64-tar-xz.json)| |Windows x86 |TAR |gz |[sfdx-win32-x86-tar-gz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-win32-x86-tar-gz.json)| |Windows x86 |TAR |xz |[sfdx-win32-x86-tar-xz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-win32-x86-tar-xz.json)| |macOS |TAR |gz |[sfdx-darwin-x64-tar-gz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-darwin-x64-tar-gz.json)| |macOS |TAR |xz |[sfdx-darwin-x64-tar-xz.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-darwin-x64-tar-xz.json)| |Windows 64 |Installer | |[sfdx-x64-exe.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-x64-exe.json)| |Windows x86 |Installer | |[sfdx-x86-exe.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-x86-exe.json)| |macOS |Installer | |[sfdx-pkg.json](https://developer.salesforce.com/media/salesforce-cli/sfdx/versions/sfdx-pkg.json)| * NEW: When you authenticate into a scratch org that wasn't created on your computer, the CLI correctly identifies it as a scratch org and associates it with its Dev Hub. This feature requires that your computer is authenticated to the Dev Hub that created the scratch org. With the Dev Hub properly identified, commands like `force:org:list` and `force:org:delete` work as expected. ([GitHub issue #398](https://github.com/forcedotcom/cli/issues/398)). * NEW: Specify more than one permission set when you use the `-n | --permsetname` parameter of the `force:user:permset:assign` command. Separate multiple names with a comma and enclose them in quotes. For example: `sfdx force:user:permset:assign -n "DreamHouse, NightmareHouse"` Thank you, [Luke Cotter, for submitting this new feature request](https://github.com/forcedotcom/cli/issues/463) and then [writing most of the code](https://github.com/salesforcecli/plugin-user/pull/102). We love that you thought of an excellent CLI improvement, and then you took the initiative and implemented the new feature yourself. We hope to see many more contributions like this from you and the community. * FIX: We've improved the warning that's displayed when you run one of the `force:source` commands and you're still using the old version of the `.forceignore` parser. ([GitHub issue #916](https://github.com/forcedotcom/cli/issues/916)) * FIX: The CLI recognizes scratch orgs created after authenticating to a Dev Hub with the `auth:jwt:grant` command. ([GitHub issue #949](https://github.com/forcedotcom/cli/issues/949)) ## 7.102.0 (May 20, 2021) - (salesforcedx 51.13.0) * FIX: We fixed some under-the-hood bugs. ## 7.101.0 (May 13, 2021) - (salesforcedx 51.12.0) * NEW: Are you a Salesforce CLI plug-in developer looking to create tests beyond simple unit tests? We've got you covered. Check out our new [@salesforce/cli-plugins-testkit](https://github.com/salesforcecli/cli-plugins-testkit) library that provides utilities for writing integration, smoke, and end-to-end tests. We also describe common use cases with associated sample code. And we link to other public GitHub repos that use the testkit so you can see the library in action. Go forth and test! * NEW: Get an approximate count of the records in standard or custom objects in your org with the new `force:limits:recordcounts:display` command. The counts are approximate because the org calculates them asynchronously and periodically rather than immediately. This example returns an approximate count of the records in the Account, Contact, Lead, and Opportunity standard objects. `sfdx force:limits:recordcounts:display -s Account,Contact,Lead,Opportunity` Thank you, [mkreth, for submitting this new feature request](https://github.com/forcedotcom/cli/issues/978) and then writing the code. We’re delighted with your solution to a real-world problem and hope to see many more contributions from you and the community. * FIX: The `force:package:version:create` command outputs correct JSON when run with the `--json` parameter. Previously the command incorrectly included console logging messages in the JSON output. ([GitHub issue #1003](https://github.com/forcedotcom/cli/issues/1003)) * FIX: We've improved the error message that's displayed when you run the `force:package:version:create` command and it can't find a file. The error now correctly describes the problem and shows the directory that's missing the file. * FIX: FIX: The `force:project:create` command generates an `.eslintignore` file that contains `**/aura/**/*.app` for Lighting Aura apps. ([GitHub issue #1004](https://github.com/forcedotcom/cli/issues/1004)) ## 7.100.0 (May 6, 2021) - (salesforcedx 51.11.0) * FIX: We fixed some under-the-hood bugs. ## 7.99.0 (April 29, 2021) - (salesforcedx 51.10.0) * NEW: Use a `.tar` file to install the Salesforce CLI release candidate. The download URL is similar to the URL for installing the current release, but uses the `stable-rc` channel instead of `stable`. For example, use this `wget` command to get the Linux release candidate `.tar` file: `wget https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable-rc/sfdx-linux-x64.tar.xz` Then install the release candidate the same way you [install the current version](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli_linux). * NEW: If you’ve already installed the current version of Salesforce CLI using the installers, run this command to switch to the release candidate: `sfdx update stable-rc` When the update completes, the core Salesforce CLI plug-ins, such as `salesforcedx`, are also updated to the release candidate version. Previously you could use only npm to install the CLI release candidate. Run this command to return to the current release: `sfdx update stable` * CHANGE: We [deprecated](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_deprecation.htm) the `force:lightning:lint` command and plan to remove it in v53.0. Use the [eslint-plugin-aura](https://github.com/forcedotcom/eslint-plugin-aura) npm package instead. * FIX: The `force:org:list` command no longer returns the error `MissingMessageError - Missing message list:noResultsFound for locale en_US` when it doesn't find non-scratch orgs in certain use cases. ## 7.98.0 (April 22, 2021) - (salesforcedx 51.9.1) * FIX: Running a Quick Deploy on a package with recently validated components no longer fails. Previously, running the command `force:source:deploy` with the `-q | --validateddeployrequestid` parameter returned the error `Unexpected element {http://soap.sforce.com/2006/04/metadata}id during simple type deserialization`. (GitHub issues [#877](https://github.com/forcedotcom/cli/issues/877) and [#876](https://github.com/forcedotcom/cli/issues/876)) ## 7.97.0 (April 15, 2021) - (salesforcedx# 51.8.0) * FIX: We fixed some under-the-hood bugs. ## 7.96.1 (April 8, 2021) - (salesforcedx 51.7.1) Before we describe the changes in this week's release, here's a quick update on open-sourcing Salesforce CLI since we published [this blog post](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021.html) in February 2021. * We've created two new public GitHub repositories and broken out the [force:data](https://github.com/salesforcecli/data) and some of the [force:org](https://github.com/salesforcecli/plugin-org) commands into their own plug-ins. * At the same time we open-sourced these plug-ins, we also fixed a bunch of GitHub issues. For example, [these issues](https://github.com/forcedotcom/cli/issues?q=is%3Aissue+is%3Aclosed+%22I+think+this+is+fixed+in+the+new+data+plugin%22) were fixed in the new data repository. Check out the [status page](https://github.com/salesforcecli/status) to get a bird’s eye view of the project. --- * NEW: Get more granular information about the code coverage results of your Apex test runs with the new `--detailedcoverage` parameter of the `force:apex:test:run` command. We've also greatly improved the code coverage results and output of the `force:apex:test:run` and `force:apex:test:report` commands. Check out the [Clearer Apex Commands](https://developer.salesforce.com/blogs/2021/04/clearer-apex-commands.html) blog post for more information and a preview of more exciting changes coming soon. Note that the upcoming improvements to the command output might break your existing scripts. * CHANGE: We changed the URLs we use to distribute the TAR files for installing Salesforce CLI. Don't worry, the URLs listed in this [manifest](https://developer.salesforce.com/media/salesforce-cli/manifest.json) still work, but starting this week we'll no longer update them to point to the latest releases. If you use these URLs in your CI/CD jobs, update your scripts with the new URLs to ensure you install the latest Salesforce CLI release. This table lists the new unversioned URLs for the TAR files (`.tar.gz` or `.tar.xz`) for each operating system. When we release a new version of Salesforce CLI every week, we also update these URLs so they point to the most up-to-date version. | Operating System | TAR Files | |------------------|--------------------------| |Linux| [sfdx-linux-x64.tar.gz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-linux-x64.tar.gz)| ||[sfdx-linux-x64.tar.xz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-linux-x64.tar.xz)| ||[sfdx-linux-arm.tar.gz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-linux-arm.tar.gz)| ||[sfdx-linux-arm.tar.xz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-linux-arm.tar.xz)| |macOS|[sfdx-darwin-x64.tar.gz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-darwin-x64.tar.gz)| ||[sfdx-darwin-x64.tar.xz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-darwin-x64.tar.xz)| |Windows*|[sfdx-win32-x64.tar.gz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-win32-x64.tar.gz)| | |[sfdx-win32-x64.tar.xz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-win32-x64.tar.xz)| | |[sfdx-win32-x86.tar.gz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-win32-x86.tar.gz)| ||[sfdx-win32-x86.tar.xz](https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-win32-x86.tar.xz)| * WINDOWS NOTE: Installing Salesforce CLI with a TAR file on Windows requires a separate program, such as 7Zip, to extract the contents. We highly recommend you use the [Windows installers](https://developer.salesforce.com/tools/sfdxcli). We also removed the `install` script from the new TAR files. The existing TAR files listed in this [manifest](https://developer.salesforce.com/media/salesforce-cli/manifest.json) still contain the `install` script. You had to have administrator privileges to run the script, and it wasn’t necessary to install Salesforce CLI anyway. We now recommend that you simply unpack the TAR file into a directory of your choice and update your PATH environment variable appropriately. We’ll update the [documentation](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli_linux) soon. * CHANGE: We've rolled back the change we announced on [February 22, 2021](./README.md#new-parameters) where some commands (`force:org:create`, `force:source:*`, and `force:mdapi:*`) use REST API by default when deploying source. These commands use SOAP API by default again. If you want to use REST for deployment, set the `restDeploy` config value or `SFDX_REST_DEPLOY` environment variable to `true`. For example, to set it globally with the config variable: `$ sfdx config:set restDeploy=true --global` To set it for just your project, don’t use the `--global` flag. We’ll update the [documentation](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_config_values.htm) soon. ## 7.94.3 (April 1, 2021) - (salesforcedx 51.6.0) * NEW: Get a list of files in your project that the `force:source:*` commands ignore with the new `force:source:ignored:list` command. The command refers to the `.forceignore` file to determine the list of ignored files. Run the command without any parameters to get a list of all the files in all package directories that are ignored. Use the `--sourcepath` parameter to limit the check to a specific file or directory. If you specify a directory, the command checks all subdirectories recursively. For example, run this command to check if a particular file is ignored: `sfdx force:source:ignored:list --sourcepath=package.xml` Run this command to get a list of all ignored files in a specific directory: `sfdx force:source:ignored:list --sourcepath=force-app/main/default` * NEW: Here at Salesforce, we love metadata! We're always looking for ways to improve moving it between orgs. And we feel like we haven't provided you with enough ways to deploy and retrieve it. So we're excited to introduce these new commands that provide true flexibility and power to your workflows: * `force:tooling:deploy|retrieve` * `force:source:transfer` * `force:mdapi:stash:push|pop` * `force:code:shove|wrest` Enjoy! ## 7.93.1 (March 25, 2021) - (salesforcedx 51.5.0) * FIX: The `auth:sfdxurl:store` command executes correctly when you specify a `.json` file to the `---sfdxurlfile` parameter. We also improved the command so that you can pass it the `.json` output of the `force:org:display` command. For example: ```bash sfdx force:org:display -u --verbose --json > authFile.json sfdx auth:sfdxurl:store --sfdxurlfile authFile.json ``` * CHANGE: We've removed the `force:project:upgrade` command after deprecating it in v50. ## 7.92.0 (March 18, 2021) - (salesforcedx 51.4.0) * NEW: Use the `--setuniqueusername` flag of `force:user:create` to force the newly created username, if specified in the definition file or at the command line, to be unique by appending the org ID. This feature is particularly useful in CI scripts that run multiple times. For example, let’s say your user definition file contains a `Username` attribute: ```bash { "Username": "tester@sfdx.org", "LastName": "Hobbs", ... } ``` The username `tester@sfdx.org` must be unique across the entire Salesforce ecosystem; otherwise, the `force:user:create` command fails. But if you use the same user definition file for each CI run, the command definitely fails on the second run. To ensure success, specify the `--setuniqueusername` parameter so that the resulting username looks something like `tester@sfdx.org.00D123456123456123`. Because org IDs are always unique, the username is also always unique. Thank you, Fabien Taillon, for submitting this [new feature request](https://github.com/salesforcecli/plugin-user/pull/50) and then writing most of the code. You're our first community member to contribute a feature that we then merged into our code and released. We're thrilled with your elegant solution to a real-world problem and hope to see many more contributions from you and the community. As part of [open-sourcing Salesforce CLI](https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021.html), we've broken out the source for some of the org commands (`force:org:open|list|display`) into their own [GitHub repo](https://github.com/salesforcecli/plugin-org). These commands are still in the `force` namespace and bundled in the `salesforcedx` plug-in, and they work the same as before. We don't normally announce when we open-source commands that remain in the `force` namespace. But because we made so many exciting changes this release, we thought we'd give you a few details. * NEW: The `force:org:display` command displays the scratch org’s namespace. Many thanks to Todd Halfpenny for requesting this new feature. (GitHub issue [#422](https://github.com/forcedotcom/cli/issues/422)) * CHANGE: Starting in version 52.0 of Salesforce CLI, the `--json` output of the `force:org:list` command no longer returns the property `connectedStatus` for scratch orgs. The `force:org:list` command displays a warning about this upcoming change, but be sure to update your CI/CD scripts now if they currently use this property. * FIX: GitHub issues [#361](https://github.com/forcedotcom/cli/issues/361), [#456](https://github.com/forcedotcom/cli/issues/456), [#482](https://github.com/forcedotcom/cli/issues/482), [#637](https://github.com/forcedotcom/cli/issues/637), [#666](https://github.com/forcedotcom/cli/issues/666), [#719](https://github.com/forcedotcom/cli/issues/719), [#724](https://github.com/forcedotcom/cli/issues/724) ## 7.91.0 (March 11, 2021) - (salesforcedx 51.3.0) * FIX: The `force:mdapi:deploy --runtests` command now runs the specified tests. * FIX: When you run the `force:mdapi:deploy` command with the `--json` parameter and the command fails, it returns the exit code 1. Previously it returned 0. ## 7.90.2 (March 4, 2021) - (salesforcedx 51.2.2) * CHANGE: As of v51, all `force:source` and `force:mdapi` commands use REST API by default to deploy. Previously they used SOAP API by default. Set the `restDeploy` config value or `SFDX_REST_DEPLOY` environment variable to false to switch back to SOAP. (GitHub Issues [#860](https://github.com/forcedotcom/cli/issues/860), [#870](https://github.com/forcedotcom/cli/issues/870), [#872](https://github.com/forcedotcom/cli/issues/872), [#884](https://github.com/forcedotcom/cli/issues/884)) * FIX: You no longer get the error FILE HAS NO CONTENT when you run any command after authenticating to an org with the `auth:jwt:grant` command. (GitHub Issue [#867](https://github.com/forcedotcom/cli/issues/867)) * FIX: The force:user:password:generate and force:user:create commands generate valid passwords. (GitHub Issue [#858](https://github.com/forcedotcom/cli/issues/858)) * FIX: The force:project:create command now generates a scratch org definition file with EnableSetPasswordInApi as a scratch org feature rather than a security setting. This change is a result of the field [Settings.securitySettings.passwordPolicies.enableSetPasswordInApi](https://help.salesforce.com/articleView?id=release-notes.rn_api_meta.htm&type=5&release=230) being removed in version 51.0 of the Metadata API. * FIX: When authorizing an org with `auth:web:login`, the browser no longer hangs after allowing access. (GitHub Issue [#890](https://github.com/forcedotcom/cli/issues/890)) ## 7.89.2 (February 25, 2021) - (salesforcedx 51.1.1) * FIX: The command `force:user:create` properly authenticates to a connected app authenticated with Web Flow login. ## 7.88.4 (February 22, 2021) - (salesforcedx 51.0.4) Welcome to the first release of version 51 of the `salesforcedx` CLI plug-in in Spring '21. ### Installation Notes Update Salesforce CLI to v51 by running `sfdx update`. ```bash $ sfdx update ``` If you are installing Salesforce CLI for the first time, see [Install Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli) to install the CLI for your operating system, then run `sfdx update`. Run `sfdx plugins --core` to display the version of Salesforce CLI and the installed `salesforcedx` plug-in. ```bash $ sfdx plugins --core @oclif/plugin-autocomplete 0.3.0 (core) @oclif/plugin-commands 1.3.0 (core) @oclif/plugin-help 3.2.2 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.9.5 (core) @oclif/plugin-update 1.4.0-2 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-trust 3.6.0 (core) alias 1.1.5 (core) auth 1.4.8 (core) config 1.2.4 (core) generator 1.1.5 (core) salesforcedx 51.0.2 (core) // salesforcedx plug-in version ├─ limits 1.0.3 (core) ├─ user 1.1.0 (core) ├─ schema 1.0.3 (core) ├─ apex 0.1.4 (core) ├─ templates 51.1.0 (core) ├─ custom-metadata 1.0.11 (core) ├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core) └─ salesforce-alm 51.0.1 (core) sfdx-cli 7.88.3 (core) // Salesforce CLI version telemetry 1.1.1 (core) ``` ### Uninstall the Pre-Release Version of the salesforcedx CLI Plug-In If you installed the pre-release version of the `salesforcedx` plug-in, uninstall it and update the CLI. We’re no longer updating the pre-release and will be removing the tag. ```bash $ sfdx plugins:uninstall salesforcedx $ sfdx update ``` ### The Salesforce CLI platform installers now install nodejs v14 LTS The platform installers for Salesforce CLI (Windows, Linux and Mac OS X) now install nodejs v14 LTS. ### Salesforce CLI has dropped support for nodejs v8 Nodejs v8 has reached end-of-life and is no longer maintained. Salesforce CLI supports nodejs engine v10 or greater. ### New Commands No new commands have been added in release v51. ### Removed Commands These commands were removed in v51. The ISV Hammer test closed pilot program has been terminated. * `force:package:hammertest:list` * `force:package:hammertest:report` * `force:package:hammertest:run` ### New Parameters * `force:mdapi:deploy --soapdeploy` The `--soapdeploy` parameter causes the metadata deploy to use the SOAP API. Starting in v51, the `force:mdapi:deploy` command uses REST by default; previously it used SOAP. All other commands continue to use SOAP by default. * `force:package:create --orgdependent` For unlocked packages only, allows the package to depend on unpackaged metadata in the installation org. This parameter is now GA; it was Beta in v50. ### Removed Parameters * `force:org:shape:create --definitionfile` The `definitionfile` parameter has been removed from this command. This parameter is part of the org shape feature which is currently in beta. We removed the parameter based on feedback from users that they preferred storing the org shape in the shape source org rather than in a scratch definition file. ### Second-Generation Managed Packaging * The `force:pacakge:version:report --verbose` command displays the release version stamped on a package version. * We've enhanced the package version CLI commands to support component deletion. * If `force:package:version:create` completes successfully, and metadata has been removed from the package version as compared to its ancestor, the command displays a generic warning message about the removed metadata. * The command `force:package:version:list --verbose` displays whether metadata was removed. * The command `force:package:version:report` displays whether metadata was removed. * The command `force:package:version:promote` displays a warning if components have been removed from the version being promoted and `--noprompt` isn't specified. * The `--orgdependent` parameter of `force:package:create` is GA. The parameter was beta in v50." ### Other Changes * FIX: We've improved the error message returned when you run `force:user:password:generate` using API version 51.0 and EnableSetPasswordInApi is configured as a security setting in your scratch org definition file. EnableSetPasswordInApi is now a scratch org feature instead of a Metadata API setting. Here's an example of configuring it as a feature in your scratch org definition file: `"features": ["EnableSetPasswordInApi","MultiCurrency"],` This change is a result of the field `Settings.securitySettings.passwordPolicies.enableSetPasswordInApi` being [removed in version 51.0 of the Metadata API](https://help.salesforce.com/articleView?id=release-notes.rn_api_meta.htm&type=5&release=230). (GitHub issue [#798](https://github.com/forcedotcom/cli/issues/798)) * FIX: The command `force:user:password:generate` no longer fails when generating a password for a user that doesn't have access to the Profile standard object. * FIX: The output of `force:user:create --json` now matches the output from previous versions. * FIX: The command `force:source:deploy` no longer fails with "The org cannot be found" after a successful login. * FIX: The command `force:user:password:generate` no longer fails when generating a password for a user that doesn't have access to the Profile standard object. ================================================ FILE: releasenotes/sfdx/v41.md ================================================ # Salesforce CLI v41 Release Notes Here are the new and changed features in recent updates of the Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of the Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. **Note:** You might run into these or similar exceptions when you update to a newer version of the plug-in. The exceptions don’t affect the update so you can safely ignore them. 1. `TypeError: Class extends value undefined is not a constructor or null` 1. `Error: Cannot find module ‘c:\Users\<user>\AppData\Local\sfdx\client\bin\run’` ## 41.18.3 (January 25, 2018) 1. The `force:doc:commands:display` command spawns fewer processes. Previously, the command would sometimes use too many system resources and fail. 1. We've fixed `force:mdapi:convert` to correctly convert individual subcomponents of CustomObjects into Salesforce DX format. As a result, `force:source:push` also correctly pushes custom fields or list views (or any individual component of CustomObject) to the scratch org if this CustomObject already exists in the org. 1. The `force:doc` commands show up regardless of how you update the `salesforcedx` plug-in. 1. We've improved the performance of `force:source:push` so that it uses cached elements when possible. 1. If you install the `salesforcedx` plug-in using the `plugins:install` command, you no longer get a warning about the plug-in not being signed. 1. (Windows) The `sfdx` command uses a case-insensitive comparison when comparing pathnames. ## 41.17.0 (January 18, 2018) 1. We've enhanced the `sfdx-project.json` schema so that validation catches the following errors: 1. Misspelled or undefined attributes, such as `ddependencies` (instead of `dependencies`.) 1. Missing required attributes when creating a second-generation package, such as `id`, `path`, `packageName`, and `packageBuilder`. 1. You can now push a renamed ApexClass to a scratch org. 1. The `force:source:push|pull|status` commands run faster when pushing or pulling additional items after the initial push|pull to a scratch org. ## 41.16.5 (January 11, 2018) 1. The `force:doc:commands:list --usage` command displays help for `force:lightning:lint`. 1. (Windows only) Pulling reports created in scratch orgs works correctly. If you create a report in a scratch org and then run `force:source:pull`, you see the report pulled to your project directory. 1. The `force:mdapi:convert` command correctly detects when CustomObject and CustomObjectTranslation objects are duplicated rather than changed. For example, let’s say you run `force:source:convert` to generate Metadata API-formatted source, alter a field or custom object attribute in an `*.object` file, and then run `force:mdapi:convert` on the directory. The command creates `*.dup` files for the custom field and custom object container files. Previously the command would incorrectly mark them as changed. 1. If network issues cause the CLI plugin installation to fail, the error message describes the issue clearly and provides useful information. 1. The `--externalid` parameter of `force:data:bulk:upsert` is required. 1. The `--triggerevents` parameter of `force:apex:trigger:create` accepts the following new values: 1. `before update`: Fire the trigger before an update event. 1. `after update`: Fire the trigger after an update event. ## 41.12.0 (December 14, 2017) 1. The `--where` and `--usetoolingapi` parameters of the `force:data:record:*` commands work together correctly. Previously, some combinations of parameters didn’t work. For example, if you also specified the `--sobjecttype TraceFlag` parameter, the command would incorrectly return `ERROR: sObject type 'TraceFlag' is not supported`. 1. The `force:project:create` command generates a sample `.forceignore` file in the project directory. 1. The `force:mdapi:convert` command correctly fails when converting a metadata entity, such as ApexClass, that requires both a content (`*.cls`) and metadata (`*.cls-meta.xml`) file but one is missing from the metadata API source directory. Previously, the command would succeed, but you’d later get an error when running `force:source:push`. ## 41.11.0 (December 7, 2017) 1. Use the new `force:apex:trigger:create` command to create an Apex trigger. 1. The `force:lightning:app:create` command adds two new files to the generated Lightning bundle: `<appname>.svg` and `<appname>.auradoc`. 1. The `force:lightning:component:create` command adds three new files to the generated Lightning bundle: `<componentname>.svg`, `<componentname>.auradoc`, and `<componentname>.design`. ## 41.10.0 (November 30, 2017) 1. The `force:doc:commands:list` command has a new parameter, `--usage`, which lists the docopt usage strings for all `salesforcedx` commands. 1. The `force:data:soql:query` command has a new parameter, `--resultformat`, for specifying the output format of the query results. 1. You can set the `--wait` parameter of `force:mdapi:deploy`, `mdapi:deploy:report`, `mdapi:retrieve`, and `mdapi:retrieve:report` to 0 so that the CLI returns immediately and does not perform a status request. 1. When you execute `force:apex:test:run`, Apex pre-compilation is now turned off by default. Use the `SFDX_PRECOMPILE_ENABLE=true` environment variable to turn pre-compilation on. ## 41.8.7 (November 16, 2017) 1. The `generatePassword` property of a user definition file used by `force:user:create` now correctly accepts a Boolean value. ```json { "generatePassword": true } ``` ## 41.6.0 (November 2, 2017) 1. If the `force:source:push|pull` commands run into a conflict, the output messages suggest how to fix the problem. 1. The `force:source:convert|pull` commands convert and pull all folders, including those that are empty. ## 41.5.2 (October 26, 2017) 1. The `force:mdapi:deploy:report` command reports the status of the most recently run deploy job when you run the command without a `--jobid` parameter. 1. The `force:mdapi:retrieve:report` command reports the status of the most recently run retrieve job when you run the command without a `--jobid` parameter. 1. The `force:source:push|pull` commands support WaveXmd components. 1. The `force:source:*` commands correctly track conflicts when you make changes to components within an AuraDefinitionBundle component. 1. The `force:org:create` command correctly accepts a value of 30 for the `--durationdays` parameter. ## 41.4.1 (October 19, 2017) 1. The `force:source:convert` command generates a `package.xml` that correctly deploys workflows. ================================================ FILE: releasenotes/sfdx/v42.md ================================================ # Salesforce DX CLI v42 Release Notes Here are the new and changed features in recent updates of the Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of the Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. [Click here for the v41 release notes.](./v41.md) ## 42.18.0 (May 31, 2018) 1. NEW: We prematurely announced the suspension of the locked packages pilot. The command options for locked packages will be removed in CLI v43.2.0. 1. FIX: We fixed an error where `force:source:push` was dropping the XML namespace if the original metadata was converted using `force:mdapi:convert`. The error message looked something like this: `Error parsing file: The prefix "xsi" for attribute "xsi:nil" associated with an element type "blockId" is not bound.` 1. FIX: We fixed a bug so that `force:source:convert` escapes special characters, including double quotes. 1. FIX: When running `force:data:soql:query`, the query results were incorrect if you had a lookup relationship with a null value. ## 42.17.0 (May 23, 2018) 1. CHANGE: If installing the Salesforce CLI on Windows for the first time, Windows Defender displays a warning. This message is expected because we updated the installer's code signing certificate. Click Run anyway to ignore this message. 1. FIX: Deleting a custom object translation directory was causing an error during `source:push`. 1. FIX: We fixed a bug so that `source:convert` escapes special characters. 1. FIX: The code coverage results when running all Apex tests in the Developer Console were different from the results that were reported when running `apex:test:run` or `apex:test:report`. We are providing more useful command output: 1. Test run coverage - Percentage of code coverage as exercised by the tests. 1. Org-wide coverage - Percentage of code coverage for the entire org, including classes and triggers not exercised by the tests. ## 42.16.0 (May 17, 2018) 1. We didn't release a Salesforce CLI patch this week. ## 42.15.0 (May 10, 2018) 1. FIX: Running `sfdx plugin` produces an error. The correct command is `sfdx plugins`. 1. FIX: You can install plug-ins that contain npm scoped packages. 1. FIX: You can now use a debugger to step through the plug-in generator code. 1. FIX: We improved the schema validation error message if you don't specify a valid plan file when running `force:data:import -p`. 1. CHANGE: To support plug-in development, we added a plugins section to the `sfdx-project.json` file where you'll add configuration values and settings for your plug-in. ```json "plugins": { "yourPluginName": { "timeOutValue": "2" } } ``` Here's an example of the code you'll use to access the properties: ```javascript import { Project, SfdxProjectJson } from '@salesforce/core' const project: Project = await Project.resolve(process.cwd()); const sfdxProject: SfdxProjectJson = await project.retrieveSfdxProjectJson(); const pluginSettings: any = sfdxProject.get('plugins'); this.ux.log(`timeOutValue: ${pluginSettings.yourPluginName.timeOutValue}`); ``` ## 42.14.0 (May 3, 2018) 1. NEW: Source status tracking is now available for Lightning Experience themes. 1. CHANGE: We no longer support installing the Salesforce CLI on the Windows 10 Subsystem for Linux. The Salesforce CLI works best within the native Windows command prompt (`cmd.exe`) and the Microsoft Powershell. 1. FIX: Profiles whose names contain encoded characters are now respected in `.forceignore`. 1. FIX: We've improved the performance of `force:source:convert` for source that contains profiles. ## 42.13.0 (April 26, 2018) 1. CHANGE: We improved the connection types for generated plug-ins. For existing generated plug-ins, if you decide to update to the latest `@salesforce/command` library, update your `tsconfig.json` file. * Run this command in your generated plug-in: `yarn add --dev @types/jsforce` * Remove these lines from `tsconfig.json`: ```json "baseUrl": "./", "paths" : { "*" : ["./node_modules/@salesforce/core/typings/*"] } ``` 1. FIX: You can install plug-ins that contain npm scoped packages. 1. FIX: Running `source:status` no longer causes the initial `source:push` to fail if some source folders were deleted. 1. FIX: We fixed some other minor "under-the-hood" bugs. ## 42.12.0 (April 19, 2018) 1. CHANGE: The new v6 Linux installer tarballs' root directories are versioned and change with every release. To keep the directory name consistent (especially important for CI use cases): 1. Get one of these tarballs: * `wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz` * `wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-386.tar.xz` 1. `mkdir sfdx` 1. Extract the files for your tarball version: * `tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1` * `tar xJf sfdx-linux-386.tar.xz -C sfdx --strip-components 1` 1. Run `./sfdx/install` 1. FIX: When creating a second-generation package using `package2:version:create`, permissions specified in a profile weren't being set correctly during package creation. We fixed this issue. ## 42.11.0 (April 12, 2018) 1. NEW: We announced the Salesforce Plugin Generator at TrailheaDX but it was officially released with version 42.8.0. Go to that section for details. 1. CHANGE: When you install the Salesforce CLI on Windows, we no longer install Git. Salesforce CLI no longer depends on Git. ## 42.10.0 (April 5, 2018) 1. FIX: We fixed the formatting for the error message when creating a scratch org fails. ## 42.9.0 (March 29, 2018) 1. No CLI patch this week. Come by and see us at the Salesforce DX booth in the Developer Forest at TrailheaDX! ## 42.8.0 (March 22, 2018) 1. NEW: We released the Salesforce Plugin Generator (Beta) that you can use to build plugins for the Salesforce CLI. The generated sfdx plugin and command are built on top of the oclif cli framework. See [Salesforce Plugin Generator](https://github.com/forcedotcom/sfdx-plugin-generate) for more information. 1. FIX: We fixed some very minor "under-the-hood" bugs. ## 42.7.0 (March 15, 2018) 1. NEW: We added the `-r | --noprompt` flag to `force:package:install`, which allows Remote Site Settings and Content Security Policy websites to send or receive data without confirmation. 1. FIX: We fixed a bug where Apex tests were hanging, which caused the CLI to return a socket timeout error. ## 42.6.0 (March 8, 2018) 1. FIX: We fixed some very minor "under-the-hood" bugs. ## 42.5.0 (March 1, 2018) 1. NEW: Use the `force:apex:log:get` command to fetch the specified log or given number of most recent logs from your default scratch org. 1. NEW: Use the `force:apex:log:tail` command to turn on debug logging and output logs in the terminal. You can also pipe debug logs to a file. 1. CHANGE: We improved the error message for `force:user:password:generate` to specify the required org preference. 1. CHANGE: We are removing the `--buildinstance` parameter for `force:package2:version:create`. We unintentionally exposed this internal parameter. 1. FIX: When you delete a folder, then run `force:source:push`, both the folder and its corresponding metadata file (`-meta.xml`) are deleted. 1. FIX: The `--json` flag for `force:apex:log:get` now properly returns the debug log. 1. FIX: We fixed the cryptic error message when running `force:org:open` with an access token. ## 42.4.0 (February 22, 2018) 1. The output of `sfdx force:apex:test:run --resultsformat human` includes a new section: `=== Failures`. This section includes stack traces for failed tests. In [Salesforce Extensions for VS Code](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode), these stack traces are active links to lines of your code. 1. We made some improvements to the `force:apex:test:run` command. 1. `force:apex:test:run` supports the `-w` | `--wait` parameter, but previously this option wasn't displayed in the command's `--help` output. The parameter now shows up in the help. 1. For customers with long-running Apex tests, we added an extra status check before the `force:apex:test:run` command times out. 1. We fixed a couple of bugs on Windows. 1. The `.forceignore` file is now respected consistently. We received a report that Windows users were having issues with this file in the [Trailblazer Community](https://success.salesforce.com/0D53A00003Q6Iti). 1. You can run `sfdx force:source:push` without `Path must be a string` errors, even when your project's filepaths contain forward slashes. 1. We fixed a bug that prevented usernames with only one character before the `@` sign from appearing in the `force:org:list` output. 1. We fixed an issue (reported in the [Trailblazer Community](https://success.salesforce.com/0D53A00003PV6bY)) that caused an error when you ran `sfdx force:auth:web:login -i ...` and specified a `clientSecret`: `Cannot start the OAuth redirect server on port Error`. This issue was caused by a capitalization mis-match in our code. In your `sfdx-project.json` file, the correct capitalization, `oauthLocalPort`, is now respected. ## 42.3.0 (February 15, 2018) 1. We fixed a bug that was preventing `force:apex:test:run` from honoring the `-y` | `--synchronous` flag when you provided a `-t` | `--tests` parameter. You can now use these parameters together to synchronously run individual Apex test methods from a single class. 1. We fixed a bug that caused deployment errors when your `.forceignore` file referenced all files in a subdirectory using `**` for some metadata types. Previously, including these references in your `.forceignore` file caused errors such as `Unable to load Lightning Component Source for js://c.hello_world: Invalid suffix: test.` and `In field: tab - no CustomTab named hello_world was found`. ## 42.2.1 (February 10, 2018) Welcome to the first release of the Salesforce CLI v42 in Spring '18. We have several new commands and parameters, as well as some changes to existing commands and parameters. Read all about it in the [Salesforce Release Notes](http://releasenotes.docs.salesforce.com/en-us/spring18/release-notes/rn_sf_cli.htm). Here's what's changed. ### New Commands * `force:apex:trigger:create` Creates skeleton Apex trigger source files. * `force:auth:logout` Logs you out of orgs that you previously authorized. * `force:package2:update` Updates a second-generation package. ### Changed Commands * `force:project:create` Generates a sample `.forceignore` file in your new project. ### New Parameters * `force:apex:test:run`: `-t` | `--tests` Runs individual methods of Apex test classes. * `force:apex:test:run`: `-y` | `--synchronous` Runs tests from a single Apex class synchronously. * `force:schema:sobject:describe`: `-t` | `--usetoolingapi` Executes with Tooling API. * `force:package2:version:create`: `-s` | `--buildinstance` The instance where the package version is created, for example, NA50. * `force:package2:version:create`: `-e` | `--nonamespace` Creates the package with no namespace. * `force:package2:version:update`: `-p` | `--noprompt` No prompt to confirm setting the package version as released. * `force:data:record:create`, `force:data:record:delete`, `force:data:record:get`, `force:data:record:update`, and `force:data:soql:query`: `--perfloglevel` (no short name) Gets data on API performance metrics from the server. ### Changed Parameters * `force:data:bulk:upsert`: `-i` | `--externalid` Changed from being optional to required. ### Installation and Configuration Changes The salesforcedx plug-in is bundled with the CLI. When you install the CLI, you also get the plug-in. To check the version of the installed core salesforcedx plug-in, use the --core parameter: `sfdx plugins --core` The `SFDX_DISABLE_ENCRYPTION` environment variable is no longer supported. The variable was deprecated in the previous release. ================================================ FILE: releasenotes/sfdx/v43.md ================================================ # Salesforce CLI v43 Release Notes Here are the new and changed features in recent updates of the Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of the Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. **Note:** As a beta feature, Second-Generation Packaging is a preview and isn't part of the "Services" under your master subscription agreement with Salesforce. Use this feature at your sole discretion, and make your purchase decisions only on the basis of generally available products and features. Salesforce doesn't guarantee general availability of this feature within any particular time frame or at all, and we can discontinue it at any time. This feature is for evaluation purposes only, not for production use. It's offered as is and isn't supported, and Salesforce has no liability for any harm or damage arising out of or in connection with it. All restrictions, Salesforce reservation of rights, obligations concerning the Services, and terms for related Non-Salesforce Applications and Content apply equally to your use of this feature. You can provide feedback and suggestions for second-generation packaging in the [Packaging 2 Beta](https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000Lg5U) group in the Trailblazer Community. [Click here for the v42 release notes.](./v42.md) ## 43.18.0 (September 27, 2018) 1. We aren't going to release a Salesforce CLI patch this week. Stop by and see us at the Salesforce DX booths at Dreamforce! ## 43.17.0 (September 20, 2018) 1. FIX: We fixed a bug in the Salesforce Plugin Generator that was causing the test suite to fail silently. ## 43.16.0 (September 13, 2018) 1. We didn't release a Salesforce CLI patch this week. ## 43.15.0 (September 6, 2018) 1. We didn't release a Salesforce CLI patch this week. ## 43.14.0 (August 30, 2018) 1. FIX: We fixed some minor under-the-hood bugs. ## 43.13.0 (August 23, 2018) 1. We didn't release a Salesforce CLI patch this week. ## 43.12.0 (August 16, 2018) 1. FIX: `sfdx force:mdapi:convert` successfully converts Analytics templates that contain images. ## 43.11.0 (August 9, 2018) 1. FIX: `sfdx force:source:pull` retrieves Analytics templates even if they contain datasets. 1. FIX: `sfdx force:mdapi:convert` places `waveTemplate` files into the proper nested directories: a `dashboards` directory, an `external-files` directory, and so on. Previously, all `waveTemplate` files were placed in the same directory. ## 43.10.0 (August 2, 2018) 1. FIX: We fixed some minor under-the-hood bugs. ## 43.9.0 (July 26, 2018) 1. CHANGE: We updated the `--help` output to indicate which commands you must run from within a Salesforce DX project directory. 1. CHANGE: The output is easier to read when you run `force:doc:commands:list`, especially for commands with deprecation warnings. ## 43.8.0 (July 19, 2018) 1. FIX: The column output is not repeated when you indicate a child relationship when running `data:soql:query`. ## 43.7.0 (July 12, 2018) 1. CHANGE: If a metadata name has special characters (such as forward slashes, backslashes, quotation marks), we encode the file name on the local file system for all operating systems. For example, if you pull a custom profile called `Custom: Marketing Profile`, the colon is encoded in the resulting file name. `Custom%3A Marketing Profile.profile-meta.xml` If you reference a file name with special characters in `.forceignore`, use the encoded file name. 1. FIX: When running `force:source:pull` on Windows, custom profiles are pulled correctly. 1. FIX: You can indicate a package version with a build number when defining a dependent package in the `sfdx-project.json` file. Previously, you had to indicate the `LATEST` keyword as the build number. ```json "dependencies": [ { "package": "0Hoxxx", "versionNumber": "1.1.0.3" }], ``` ## 43.6.0 (July 5, 2018) 1. FIX: We fixed some minor under-the-hood bugs. ## 43.5.1 (July 2, 2018) 1. FIX: Deployment errors for `force:source:push` show the project path. ## 43.5.0 (June 28, 2018) 1. CHANGE: For several `force:package` commands, we updated and improved the command `--help` and error messages. 1. CHANGE: When running `force:package:create`, we ignore the trailing slash (/) for the `--path` parameter. For example, the CLI treats both `force-app` and `force-app/` the same. 1. FIX: When creating a layout in a scratch org and pulling it to your local project, the layout metadata file (`-meta.xml`) is placed in the correct local directory, `<package_dir>/main/default/layouts`. 1. FIX: The `force:mdapi:convert` command escapes double quotes when converting to Salesforce DX format. 1. FIX: All environment variables override configuration variables, including `SFDX_API_VERSION`. ## 43.4.0 (June 21, 2018) 1. CHANGE: We changed the output for `force:package:version:list`. The output includes a new column that indicates whether the package version is protected by an installation key. To view the Package Version ID and Installation URL information, run the command with the `--verbose` parameter. 1. CHANGE: Where you run the `force:package:install` and `force:package:uninstall` commands matter depending on whether you indicate a package version ID (04t) or package version alias. If using the package version ID, you can run the commands outside of a Salesforce DX project. If using the package alias, run the commands from within a Salesforce DX project. The `sfdx-project.json` file is required to map the package version alias to its package version ID. ## 43.3.0 (June 14, 2018) 1. CHANGE: We collect usage information, user environment, and crash reports for the purposes of providing services or functions that are relevant to use of the Salesforce CLI and for product improvements. 1. CHANGE: If you use package version IDs instead of aliases, you can now use 04t package IDs for all `force:package:version` commands instead of a mix of 04t (subscriber package version) and 05i (package version) IDs. However, we strongly recommend using aliases for all `force:package` commands and in the `sfdx-project.json` file. 1. The output displays only the 04t IDs for `package:version:create`, `package:version:update`, `package:version:list`, and `package:version:report`. 1. You can use either 04t or 05i IDs when running `package:version:update`, `package:version:promote`, or `package:version:report`. 1. You can use either 04t or 05i IDs as the ancestor ID in the `sfdx-project.json` file. 1. You can view 05i IDs for `package:version:list` and `package:version:report` if you use the `--verbose` parameter. 1. CHANGE: The `--path | -r` parameter for `force:package:create` is required. 1. CHANGE: We renamed several parameters for `force:package:version:update` to make them consistent with the parameters for `force:package:version:create`. 1. `--name | -n` is now `--versionname | -a` 1. `--description | -d` is now `--versiondescription | -e` 1. `--package2versionid | -i` is now `--package | -p` 1. FIX: The Summer '18 release notes were updated to indicate the correct short flag for `force:package:create --path`. It's `-r`. 1. FIX: We improved the behavior for source tracking when you delete an object's `.object-meta.xml` file. 1. If you delete the `.object-meta.xml` file for a custom object, and your local source contains fine-grained items for the custom object, you see an error message. Custom objects require a corresponding metadata file. 1. If you delete the `.object-meta.xml` file for a custom object and its associated decomposed files, but leave empty directories in your local project for those objects, the CLI deletes the directories for you. 1. If you delete the `.object-meta.xml` file for a standard object, the `force:source` commands run successfully. The `.object-meta.xml` file is not required for standard objects. ## 43.2.9 (June 9, 2018) Welcome to the first release of the Salesforce CLI v43 in Summer '18. We have several new commands and parameters, as well as some changes to existing commands and parameters. Read all about it in the [Salesforce Release Notes](http://releasenotes.docs.salesforce.com/en-us/summer18/release-notes/rn_sf_cli.htm). Here's what's changed. ### New Commands * `plugins:generate` Use the Salesforce Plugin Generator to build plug-ins for the Salesforce CLI. The generated sfdx plug-in and command are built on top of the oclif cli framework. See https://github.com/forcedotcom/sfdx-plugin-generate for more information. * `force:apex:log:get` Use this command to fetch the specified debug log or given number of most recent logs from your default scratch org. * `force:apex:log:tail` Use this command to turn on debug logging and output logs in the terminal. You can also pipe debug logs to a file. ### Changed Commands * `force:package` Commands Replace `force:package2` Commands We are streamlining all second-generation packaging commands and adding several new parameters that make creating packages easier and more intuitive. You can continue to use the `force:package2` commands until they are deprecated in Winter '19. The `force:package1` commands, which you use to create first-generation package versions, are unchanged. See [Salesforce Release Notes](http://releasenotes.docs.salesforce.com/en-us/summer18/release-notes/rn_sfdx_packaging_commands.htm) for details. * `force:source` Commands Source status tracking is now available for Lightning Experience themes. ### New Parameters `force:package:install -r | --noprompt` This flag allows Remote Site Settings and Content Security Policy websites to send or receive data without confirmation. ### Changed Parameters * `force:apex:test:run -c | --codecoverage` To improve performance, we calculate and retrieve code coverage results for `force:apex:test:run` only when you supply the `-c | --codecoverage` flag. * `sfdx force:apex:test:run --resultsformat human` The output now includes a new section: `=== Failures`. This section includes stack traces for failed tests. In [Salesforce Extensions for VS Code](https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode), these stack traces are active links to lines of your code. * `force:package2:version:create --buildinstance` We removed this parameter because it is for internal use only and was unintentionally exposed. ### Installation and Configuration Changes #### v6 Linux Tarballs' Root Directories Are Versioned The new v6 Linux installer tarballs' root directories are versioned and change with every release. To keep the directory name consistent (especially important for CI use cases): * Get one of these tarballs: `wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz` `wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-386.tar.xz` * Create an `sfdx` folder: `mkdir sfdx` * Extract the files for your tarball version: `tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components` `tar xJf sfdx-linux-386.tar.xz -C sfdx --strip-components 1` * Run `./sfdx/install`. #### Windows 10 Subsystem for Linux We no longer support installing the Salesforce CLI on the Windows 10 Subsystem for Linux. The Salesforce CLI works best within the native Windows command prompt (cmd.exe) and the Microsoft Powershell. #### Windows Installer Updates When you install the Salesforce CLI on Windows, we no longer install Git. Salesforce CLI no longer depends on Git. ### Salesforce Plugin Generator (Beta) We released the Salesforce Plugin Generator (Beta) that you can use to build plug-ins for the Salesforce CLI. The generated sfdx plug-in and command are built on top of the Open CLI Framework. See [Salesforce Plugin Generator](https://github.com/forcedotcom/sfdx-plugin-generate) for more information. #### Plug-in Development Support To support plug-in development, we added a plugins section to the `sfdx-project.json` file. In this section, add configuration values and settings for your plug-in. ```json "plugins": { "yourPluginName": { "timeOutValue": "2" } } ``` Here's an example of the code you use to access the properties: ```javascript import { Project, SfdxProjectJson } from '@salesforce/core' const project: Project = await Project.resolve(process.cwd()); const sfdxProject: SfdxProjectJson = await project.retrieveSfdxProjectJson(); const pluginSettings: any = sfdxProject.get('plugins'); this.ux.log('timeOutValue: ${pluginSettings.yourPluginName.timeOutValue}'); ``` #### Improved Connection Types for Generated Plug-ins For existing generated plug-ins, if you decide to update to the latest `@salesforce/command` library, update your `tsconfig.json` file. * Run this command in your generated plug-in: `yarn add --dev @types/jsforce` * Remove these lines from `tsconfig.json`: ```json "baseUrl": "./", "paths" : { "*" : ["./node_modules/@salesforce/core/typings/*"] } ``` ================================================ FILE: releasenotes/sfdx/v44.md ================================================ # Salesforce CLI v44 Release Notes Here are the new and changed features in recent updates of the Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of the Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. **Note:** As a beta feature, second-generation managed packages and non-source-tracked org commands are a preview and aren't part of the "Services" under your master subscription agreement with Salesforce. Use these features at your sole discretion, and make your purchase decisions only on the basis of generally available products and features. Salesforce doesn't guarantee general availability of these features within any particular time frame or at all, and we can discontinue them at any time. These features are for evaluation purposes only, not for production use. They're offered as is and aren't supported, and Salesforce has no liability for any harm or damage arising out of or in connection with them. All restrictions, Salesforce reservation of rights, obligations concerning the Services, and terms for related Non-Salesforce Applications and Content apply equally to your use of these features. You can provide feedback and suggestions for second-generation managed packages in the [Packaging 2 Beta](https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000Lg5U) group in the Trailblazer Community. You can provide feedback and suggestions for non-source-tracked org commands in the [Salesforce DX](https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000HTp1) group in the Trailblazer Community. **Note:** We provide Scratch Org Snapshot to selected customers through a pilot program that requires agreement to specific terms and conditions. To be nominated to participate in the program, contact Salesforce. Pilot programs are subject to change, and we can't guarantee acceptance. Scratch Org Snapshot isn't generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. We can't guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features. For information on enabling this feature in your org, contact Salesforce. [Click here for the v43 release notes.](./v43.md) ## 44.18.0 (January 31, 2019) 1. FIX: Salesforce CLI uses a new connected app as the default for web login. All existing authorized orgs will continue to work. This fix resolves this [known issue](https://success.salesforce.com/issues_view?id=a1p3A000000BMnj): ```text Scratch Org sign up is failing with an error "We encountered a problem while attempting to configure and approve the Connected App for your org." ``` 1. FIX: When running `force:source:pull`, we include the `.xml` extension for XML static resources (XML MIME types). ## 44.17.0 (January 24, 2019) 1. FIX: We fixed an issue where users received an expired access token error after: 1. Authorizing a Dev Hub org using the JWT-based flow 1. Creating a scratch org 1. Running `force:user:create` 1. Running a CLI command that requires authorization, such as `force:org:open` The error message starts with this text: ```text ERROR: This org appears to have a problem with its OAuth configuration. Reason: invalid_grant - expired access/refresh token ``` ## 44.16.0 (January 17, 2019) 1. FIX: We fixed some minor under-the-hood bugs. ## 44.15.0 (January 10, 2019) 1. FIX: We fixed some minor under-the-hood bugs. ## 44.14.0 (January 3, 2019) 1. We didn't release a Salesforce CLI patch this week. ## 44.13.0 (December 27, 2018) 1. We didn't release a Salesforce CLI patch this week. ## 44.12.0 (December 20, 2018) 1. We didn't release a Salesforce CLI patch this week. ## 44.11.0 (December 13, 2018) 1. FIX: You no longer see a socket connection reset when you execute a status query on 1,300 or more Apex class IDs. The connection reset resulted in this error: ```text Error: read ECONNRESET ``` ## 44.10.0 (December 6, 2018) 1. CHANGE: `force:package:install` includes an optional new `--upgradetype | -t <upgradetype>` parameter. For package upgrades, you can now specify options for deprecation or deletion of removed components. To delete components that can be safely deleted and deprecate the others, specify `--upgradetype Mixed` (the default). To deprecate all removed components, specify `--upgradetype DeprecateOnly`. ## 44.9.0 (November 29, 2018) 1. FIX: Running `force:user:display` no longer generates this error: ```text ERROR: logger is not defined. ``` ## 44.8.0 (November 20, 2018) 1. FIX: A Streaming API issue was affecting `apex:test:report`, `apex:test:run --wait`, and `org:create`. These commands now function properly. ## 44.7.0 (November 15, 2018) 1. NEW: You can now restrict access to an installed package to the administrator's profile and any profile with the Customize Application permission. By default, installed packages are accessible to all user profiles. Include the optional `-s | --securitytype` parameter when you run the `package:install` command. Possible values for `--securitytype` are `AllUsers` (the default) and `AdminsOnly`. ```bash sfdx force:package:install --securitytype AdminsOnly ... ``` 1. NEW: The `mdapi:deploy` command offers a quick deploy option. This option deploys a recently validated set of components without running Apex tests. To use quick deploy, add the `-q | --validateddeployrequestid` parameter with a job ID value: ```bash sfdx force:mdapi:deploy --validateddeployrequestid <JOBID> ... ``` You can run this option after you have run tests and performed a check-only deployment using the `-c | --checkonly` option: ```bash sfdx force:mdapi:deploy --checkonly ... ``` The check-only option performs a test deployment (validation) of components without saving the components in the target org. ## 44.6.0 (November 8, 2018) 1. We didn't release a Salesforce CLI patch this week. ## 44.5.0 (November 1, 2018) 1. FIX: We fixed some minor under-the-hood bugs. ## 44.4.0 (October 25, 2018) 1. NEW: You can now cancel an in-progress metadata deployment by running `force:mdapi:deploy:cancel --jobid <JOBID>`. ## 44.3.0 (October 18, 2018) 1. CHANGE: We removed the deprecated `force:package2`, `package:install:get`, and `package:uninstall:get` commands from the CLI. 1. CHANGE: Some `force:package:install` parameters have changed. We removed the deprecated `-i | --id` parameter. We added the short flags `-b` for `--publishwait` and `-p` for `--package`. 1. CHANGE: We removed the deprecated `-i | --id` parameter for `force:package:uninstall`. 1. FIX: We fixed a bug where `data:soql:query` wasn't returning results in some cases. ## 44.2.0 (October 13, 2018) Welcome to the first release of the Salesforce CLI v44 in Winter '19. We have several new commands and parameters, as well as some changes to existing commands and parameters. Here's what's changed. ### Uninstall the Pre-Release Version of the CLI If you installed the pre-release version 44 of the CLI, uninstall it, then run the update command. ```bash sfdx plugins:uninstall salesforcedx sfdx update ``` ### New Commands These new commands are available in Salesforce CLI v44. * `force:source:delete` (beta) Deletes metadata from a non-source-tracked org, such as a sandbox, and from your local project. You can indicate a comma-delimited list of local paths or of individual metadata components. * `force:source:deploy` (beta) Deploys source from your project to a non-source-tracked org. Unlike the `force:source:push` command for scratch orgs (source-tracked orgs), you indicate the specific set of metadata to deploy. This command overwrites all corresponding metadata in the org with the deployed local files. * `force:source:retrieve` (beta) Retrieves source from a non-source-tracked org to your project. Unlike the `force:source:pull` command for scratch orgs (source-tracked orgs), with `force:source:retrieve` you indicate the specific set of metadata to retrieve. This command overwrites all local files with the metadata retrieved from the org. The retrieved metadata is in source format. The Scratch Org Snapshot commands are available as part of an invitation-only pilot in late October 2018. * `force:org:snapshot:create` (pilot) Creates a snapshot of an existing scratch org to use as a basis for scratch org creations. A snapshot reflects the state of a scratch org when the snapshot is created. It contains scratch org shape information (edition, features, and licenses), installed packages, metadata, and test data. * `force:org:snapshot:delete` (pilot) Deletes a snapshot. * `force:org:snapshot:get` (pilot) Returns information for a specified snapshot. * `force:org:snapshot:list` (pilot) Lists all snapshots associated with a Dev Hub. ### Changed Commands The functionality for these commands changed in Salesforce CLI v44. * `force:mdapi:convert` This command escapes double quotes when converting from metadata format to the source format. * `force:package:install`, `force:package:uninstall` If you run these commands using the package version alias, you must run them from within a Salesforce DX project folder. If you specify the package version ID (which starts with 04t), you can run them outside of a DX project. * `force:package:version:list` The output includes a new column that indicates whether the package version is protected by an installation key. * `force:source:push` Deployment errors show the project path. * `force:source:pull` If a metadata name has special characters (such as forward slashes, backslashes, or quotation marks), we encode the file name on the local file system for all operating systems. For example, if you pull a custom profile called `Custom: Marketing Profile`, the colon is encoded in the resulting file name. ```text Custom%3A Marketing Profile.profile-meta.xml ``` If you reference a file name with special characters in `.forceignore`, use the encoded file name. If you use package version IDs instead of aliases, you can now use 04t package IDs for all `force:package:version` commands instead of a mix of 04t (subscriber package version) and 05i (package version) IDs. However, we strongly recommend using aliases for all `force:package` commands and in the `sfdx-project.json` file. 1. The output displays only the 04t IDs for `package:version:create`, `package:version:update`, `package:version:list`, and `package:version:report`. 1. You can use either 04t or 05i IDs when running `package:version:update`, `package:version:promote`, or `package:version:report`. 1. You can use either 04t or 05i IDs as the ancestor ID in the `sfdx-project.json` file. 1. You can view 05i IDs for `package:version:list` and `package:version:report` if you use the `--verbose` parameter. ### New Parameters This command has a new parameter in Salesforce CLI v44. * `force:project:create` Use the `--manifest | -x` parameter to generate a default manifest (`package.xml`) for fetching Apex, Visualforce, Lightning components, and static resources. ### Changed Parameters These parameters have changed in Salesforce CLI v44. * `force:package:create --path | -r` The `--path | -r` parameter is required. This parameter ignores trailing slashes. For example, the CLI treats both `force-app` and `force-app/` the same. * `force:package:version:update` We renamed several parameters to make them consistent with the parameters for `force:package:version:create`.
          Previous ParameterCurrent Parameter
          `--name` or `-n``--versionname` or `-a`
          `--description` or `-n``--versiondescription` or `-e`
          `--package2versionid` or `-i``--package` or `-p`
          ### Package Version in Salesforce DX Project File You can indicate a package version with a build number when defining a dependent package in the `sfdx-project.json` file. Previously, you had to indicate the `LATEST` keyword as the build number. ```json "dependencies": [ { "package": "0Hoxxx", "versionNumber": "1.1.0.3" } ] ``` ### New Environment Variables #### SFDX_MDAPI_TEMP_DIR Normally, when you run some CLI commands, a temporary directory with all the metadata is created then deleted upon successful completion of the command. However, retaining these files can be useful for several reasons. You can debug problems that occur during command execution. You can use the generated `package.xml` when running subsequent commands, or as a starting point for creating a manifest that includes all the metadata you care about. To retain all the metadata in a specified directory path when you run these commands, set the `SFDX_MDAPI_TEMP_DIR` environment variable: 1. `force:source:deploy` 1. `force:source:retrieve` 1. `force:source:delete` 1. `force:source:push` 1. `force:source:pull` 1. `force:source:convert` 1. `force:org:create` (if your scratch org definition contains scratch org settings, not org preferences) Example: ```text SFDX_MDAPI_TEMP_DIR=/users/myName/myDXProject/metadata ``` #### SFDX_JSON_TO_STDOUT You can send Salesforce CLI error output to stdout by setting the `SFDX_JSON_TO_STDOUT` environment variable to `true`. By default, Salesforce CLI sends output to stdout when a command succeeds, and to stderr if a command fails. Setting this environment variable to `true` is particularly helpful for scripting use cases. We plan to send Salesforce CLI error output to stdout by default in CLI v45. ================================================ FILE: releasenotes/sfdx/v45.md ================================================ # Salesforce CLI v45 Release Notes Here are the new and changed features in recent updates of Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. **Note:** As a beta feature, second-generation managed packages and non-source-tracked org commands are a preview and aren't part of the "Services" under your master subscription agreement with Salesforce. Use these features at your sole discretion, and make your purchase decisions only on the basis of generally available products and features. Salesforce doesn't guarantee general availability of these features within any particular time frame or at all, and we can discontinue them at any time. These features are for evaluation purposes only, not for production use. They're offered as is and aren't supported, and Salesforce has no liability for any harm or damage arising out of or in connection with them. All restrictions, Salesforce reservation of rights, obligations concerning the Services, and terms for related Non-Salesforce Applications and Content apply equally to your use of these features. You can provide feedback and suggestions for second-generation managed packages in the [Packaging 2 Beta](https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000Lg5U) group in the Trailblazer Community. You can provide feedback and suggestions for non-source-tracked org commands in the [Salesforce DX](https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000HTp1) group in the Trailblazer Community. **Note:** We provide Scratch Org Snapshot to selected customers through a pilot program that requires agreement to specific terms and conditions. To be nominated to participate in the program, contact Salesforce. Pilot programs are subject to change, and we can't guarantee acceptance. Scratch Org Snapshot isn't generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. We can't guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features. For information on enabling this feature in your org, contact Salesforce. [Click here for the v44 release notes.](v44.md) ## June 6, 2019 We aren't releasing a Salesforce CLI patch this week. ## 45.17.0 (May 30, 2019) We aren't releasing a Salesforce CLI patch this week. If you're attending TrailheaDX, stop by and see us at the Salesforce DX booths! If you can't make it in person, watch the live stream of the Salesforce <3 DX session at 3:00 PM PST on Wednesday (May 29) to hear all about what we've been building: [https://www.salesforce.com/video/5646657](https://www.salesforce.com/video/5646657/). ## 45.16.0 (May 23, 2019) 1. FIX: We fixed some under-the-hood bugs. ## 45.15.6 (May 16, 2019) 1. FIX: After you create a scratch org with org preferences, the `force:source:pull` command no longer erroneously detects the `OrgPreference.settings-meta.xml` file as changed before any changes are made in a scratch org. ## 45.14.1 (May 9, 2019) 1. FIX: We fixed some under-the-hood bugs. ## 45.13.0 (May 2, 2019) 1. FIX: You no longer see the following error when retrieving a WaveTemplateBundle component using a manifest. ```text ERROR running force:source:retrieve: Cannot read property 'getWorkspaceElements' of undefined ``` ## 45.12.0 (April 25, 2019) 1. CHANGE: We hid the `-c | --contenttype` parameter from `force:data:tree:import` because we support only one file type, JSON, so the parameter had no effect. If you happen to reference this parameter in a script, your script will continue to work. However, we suggest that you update your scripts to remove the hidden parameter, because we might remove it in the future. ## 45.11.1 (April 18, 2019) ### Install the Pre-Release Version of the CLI Would you like to get a preview of and start trying out the changes we'll be releasing in June? Install the pre-release version of `salesforcedx` v46. We'll update the [Summer '19 Salesforce CLI release notes](http://releasenotes.docs.salesforce.com/en-us/summer19/release-notes/rn_sf_cli_nc.htm) (available on April 22, 2019) as we add new and changed commands and parameters. ```bash sfdx plugins:install salesforcedx@pre-release ``` Make sure that you have the pre-release version. ```bash sfdx plugins --core salesforcedx 46.0.1-xx ``` When we officially release v46 on June 15, 2019, uninstall the pre-release, then update the CLI. ```bash sfdx plugins:uninstall salesforcedx sfdx update ``` ### Other CLI Changes 1. FIX: We fixed some under-the-hood bugs. ## 45.10.1 (April 11, 2019) 1. CHANGE: The (all commands) `--loglevel` parameter temporarily supports uppercase parameter values in Spring '19 (`salesforcedx` v45). The oclif framework checks parameter values case-sensitively, and the official `--loglevel` values are lowercase. In Summer '19 (`salesforcedx` v46), we plan to support only lowercase `--loglevel` values and remove support for uppercase values. 1. FIX: You can use any capitalization scheme when creating a package alias. It doesn't need to be heads-down camelcase. 1. FIX: Running `force:source:push --json` returns warnings in an array, as it previously did in `sfdx-cli` v6. 1. FIX: Salesforce CLI reports an error if a data file contains invalid data when running `force:data:tree:import`. ## 45.9.0 (April 4, 2019) 1. CHANGE: The (all commands) `--loglevel` parameter supports parameter values in only lowercase (due to the migration to oclif). To assist you with the transition, we plan, in a future release, to enable support for uppercase parameters in Spring '19 but deprecate support in Summer '19. 1. FIX: The `force:data:bulk:upsert` command sets job statuses to `Closed` after processing all the records. 1. FIX: You can specify `-h` to view help for these commands: 1. `data:soql:query` 1. `apex:test:run` 1. `apex:test:report` 1. `lightning:test:run` ## 45.8.2 (March 28, 2019) Salesforce CLI (`sfdx-cli`) v7 is bundled with the `salesforcedx` plug-in. Run `sfdx update` to install the new version. Use `sfdx plugins:install` only when installing a specific `salesforcedx` plug-in version. If you see the error, `Error: Cannot find module '@oclif/config'`, uninstall the `salesforcedx` plug-in. ```bash sfdx plugins:uninstall salesforcedx ``` 1. FIX: The `force:mdapi:deploy` command correctly rolls back the deployment for any failure (by default). 1. FIX: You can indicate a `--plan` when running `force:data:tree:import`. ## 45.8.1 (March 28, 2019) We have migrated Salesforce CLI to Heroku's Open CLI Framework (oclif). This framework fixes several long-standing issues with CLI updates, provides better CLI load times, and prepares us to incorporate important features in the future, like custom execution hooks and built-in autocompletion. ### Install a Previous Version of Salesforce CLI By default, the latest version of the `salesforcedx` plug-in is installed when you install Salesforce CLI for the first time. You can install a previous version of the `salesforcedx` plug-in if your specific situation requires it. 1. Salesforce CLI v7 is required for `salesforcedx` plug-in version 45.8.0 or later. 1. Salesforce CLI v6 is required for `salesforcedx` plug-in version 45.5.0 or earlier. Using npm: ```bash npm install sfdx-cli@6 --global ``` Using the installer: 1. [Darwin (Linux)](https://developer.salesforce.com/media/salesforce-cli/sfdx-cli/channels/stable/sfdx-cli-v6.56.0-e3fd846a1f.pkg) 1. [Linux 64 bit](https://developer.salesforce.com/media/salesforce-cli/sfdx-cli/channels/stable/sfdx-cli-v6.56.0-e3fd846a1f-linux-x64.tar.xz) 1. [Linux 32 bit](https://developer.salesforce.com/media/salesforce-cli/sfdx-cli/channels/stable/sfdx-cli-v6.56.0-e3fd846a1f-linux-x86.tar.xz) 1. [Linux ARM](https://developer.salesforce.com/media/salesforce-cli/sfdx-cli/channels/stable/sfdx-cli-v6.56.0-e3fd846a1f-linux-arm.tar.xz) 1. [Windows 64 bit](https://developer.salesforce.com/media/salesforce-cli/sfdx-cli/channels/stable/sfdx-cli-v6.56.0-e3fd846a1f-x64.exe) 1. [Windows 32 bit](https://developer.salesforce.com/media/salesforce-cli/sfdx-cli/channels/stable/sfdx-cli-v6.56.0-e3fd846a1f-x86.exe) ### Other CLI Changes 1. NEW: The `force:auth:list`command generates a list of usernames that you have authorized. This list is created from the usernames that are stored locally in your `.sfdx` directory. Unlike `force:org:list`, the `force:auth:list` command doesn't check whether the orgs associated with the usernames are still valid. So, the new command runs much more quickly. 1. CHANGE: Help output has a new look in v7 but works the same (by appending `--help` or `-h` to the end of a command). However, run `--help` for these commands (instead of `-h`). We plan to make `-h` work for these commands in a future release. 1. `data:soql:query` 1. `apex:test:run` 1. `apex:test:report` 1. `lightning:test:run` 1. CHANGE: We recently updated the default connected app. This change sometimes affects how `force:auth:sfdxurl:store` works during CI jobs. If you see an error (after upgrading to this CLI version) about an expired access/refresh token, regenerate the SFDX auth URL. 1. CHANGE: When you indicate `--json` output for a CLI command, the output is color-coded. If you see a parsing error on stdout, you can set this environment variable to turn it off: ```text FORCE_COLOR=0 ``` 1. CHANGE: The output for sfdx `force:doc:commands:display --json` has changed in v7. If you're processing the output for this command, compare the V6 output and update your code to reflect the new V7 JSON output. 1. FIX: When running the `force:data:tree:import` command, you can import objects with numbers in their namespaces. ## 45.7.0 (March 21, 2019) We aren't releasing a patch this week. See 45.5.0 (March 7, 2019) for information about the migration to oclif. ## 45.6.0 (March 14, 2019) We aren't releasing a patch this week. See 45.5.0 (March 7, 2019) for information about the migration to oclif. ## 45.5.0 (March 7, 2019) We are migrating the `cli-engine` framework over to Heroku's Open CLI Framework (oclif) in the coming weeks. This migration is a major update for Salesforce CLI and our core plug-ins. To allow time for testing and to facilitate a smooth transition, we will not be releasing updates for the next 3 weeks. We plan to release our next update, v45.8.x of the `salesforcedx` aggregate plug-in and and v7.x.x of `sfdx-cli`, on Thursday, March 28, 2019. We expect this change to improve the performance and reliability of Salesforce CLI and to help us add new functionality more quickly. Migrating Salesforce CLI to oclif will not change the way you interact with the CLI, and the `force` commands will work as they did before. **However, Salesforce CLI will NOT be backwards compatible with plug-ins built on the original CLI engine.** If the plug-in was created using Salesforce Plug-In Generator (`sfdx plugins:generate`), it will still work, because the generator already uses oclif. To learn more about oclif, you can visit their [website](https://oclif.io/). 1. FIX: To address the dependency on the natural-orderby library when running the `plugins:link` command, we now bundle Node.js v8.15.1 with Salesforce CLI. 1. FIX: The SFDX_NPM_REGISTRY environment variable now recognizes the full URL, and not just the domain. However, we support only repositories that don't require authentication. 1. FIX: The `force:data:bulk:upsert` command correctly parses line breaks in CSV files. ## 45.4.1 (February 28, 2019) 1. NEW: The `force:mdapi:listmetadata` command displays properties of metadata components of a specified type. This call is useful when you want to identify individual components in your manifest file or want a high-level view of particular components in your organization. This command is similar to the Metadata API utility call [listMetadata()](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_listmetadata.htm). 1. FIX: You can now retrieve specific Lightning web components to your local project on a Windows machine using `force:source:retrieve`. ```json sfdx force:source:retrieve -m LightningComponentBundle:helloworld ``` ## 45.3.1 (February 21, 2019) 1. NEW: The `force:project:create --template` parameter now accepts the values empty and standard. Using a `--template` value takes the guesswork out of the Salesforce DX project structure. For Spring '19, the default is empty, which provides a minimal amount of scaffolding (maintaining the command's previous behavior). In Summer '19, the default will be standard, which provides extended scaffolding to facilitate pushing and pulling source to and from your scratch org (especially helpful if you use Salesforce Extensions for VS Code). Selecting the standard value also adds these files: 1. `.vscode/extensions.json`: Causes Visual Studio Code, when launched, to prompt you to install the recommended extensions for your project. 1. `.vscode/settings.json`: By default, this file has one setting, for push or deploy on save, which is set to false. You can change this value or add other settings. 1. `.vscode/launch.json`: Configures Replay Debugger, making it more discoverable and easier to use. 1. `.gitignore`: Makes it easier to start using Git for version control. 1. `.prettierrc` and `.prettierignore`: Make it easier to start using Prettier to format your Aura components. Support for Lightning web components in Prettier is coming soon. 1. FIX: You can retrieve all Lightning web component resources to your local project on a Windows machine using `force:source:retrieve`. ```bash sfdx force:source:retrieve -m LightningComponentBundle ``` ## 45.2.0 (February 14, 2019) 1. NEW: The `force:mdapi:describemetadata` command displays details about metadata types enabled for your org. Use this information to identify the syntax needed for a `<name>` element in `package.xml`. The most recent API version is the default, or you can specify an older version. This command is similar to the Metadata API utility call [describeMetadata()](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_describe.htm). ## 45.1.2 (February 9, 2019) Welcome to the first release of version 45 of the `salesforcedx` plug-in for Salesforce CLI in Spring '19. Here's what's changed. ### Uninstall the Pre-Release Version of the `salesforcedx` CLI Plug-In If you installed the pre-release version 45 of the `salesforcedx` plug-in, uninstall it, then run the update command. ```bash sfdx plugins:uninstall salesforcedx sfdx update ``` ### Build Your Own Salesforce CLI Plug-In with Open-Source Tools Plug-ins add functionality to Salesforce CLI. Salesforce includes several plug-ins when you install the CLI that provide commands and functionality to meet common needs that customers and partners have. You can also choose to install other plug-ins built by Salesforce and others. But when you have requirements that existing plug-ins don't meet, Salesforce Plug-In Generator simplifies building your own using Node.js. Salesforce Plug-In Generator and the CLI `@salesforce/core` and `@salesforce/command` libraries are open source. Changes to Salesforce Plug-In Generator are released regularly. For information about weekly releases, see the [change log](https://github.com/forcedotcom/sfdx-plugin-generate/blob/master/CHANGELOG.md). For information about using Salesforce Plug-In Generator to create your own plug-in, check out the [Salesforce CLI Plug-In Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins). For useful resources, such as the open-source repositories for the plug-in generator and its dependencies, see the guide's [Resources for Salesforce CLI Plug-In Development](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins_resources.htm). ### New Commands These new commands are available in `salesforcedx` v45. * `force:mdapi:deploy:cancel`: Cancels an in-progress metadata deployment. ### New Parameters This command has a new parameter in `salesforcedx` v45. * `force:lightning:component:create --type`: Specifies whether to create an Aura component (`--type aura`, the default) or a Lightning web component (`--type lwc`). ================================================ FILE: releasenotes/sfdx/v46.md ================================================ # Salesforce CLI v46 Release Notes Here are the new and changed features in recent updates of Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. **Note:** As a beta feature, second-generation managed packages are a preview and aren't part of the "Services" under your master subscription agreement with Salesforce. Use this feature at your sole discretion, and make your purchase decisions only on the basis of generally available products and features. Salesforce doesn't guarantee general availability of this feature within any particular time frame or at all, and we can discontinue them at any time. This feature is for evaluation purposes only, not for production use. It's offered as is and isn't supported, and Salesforce has no liability for any harm or damage arising out of or in connection with it. All restrictions, Salesforce reservation of rights, obligations concerning the Services, and terms for related Non-Salesforce Applications and Content apply equally to your use of this feature. You can provide feedback and suggestions for second-generation managed packages in the [Packaging 2 Beta](https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000Lg5U) group in the Trailblazer Community. [Click here for the v45 release notes.](./v45.md) ## 46.18.0 (October 10, 2019) We aren't releasing a Salesforce CLI patch this week. ## 46.17.0 (October 3, 2019) 1. FIX: If you delete a custom label in a scratch org, the `force:source:status` command recognizes the remote change. 1. FIX: On Windows, when running `force:source:push` on a Lightning web component that contains an error, the command identifies which file is causing the error. ## 46.16.0 (September 26, 2019) 1. FIX: A remote, deleted custom label is included in the output when you run `force:source:status`. 1. FIX: The `force:source:retrieve -p` parameter retrieves an individual file from within an Aura definition bundle. ## 46.15.3 (September 19, 2019) 1. FIX: On macOS, the temporary zip file created when running `force:source:push`, `force:source:deploy`, or `force:mdapi:deploy` once again contains files that are symbolically linked. 1. FIX: The `force:source:delete` command doesn't delete the specified metadata, as expected, if you cancel the operation when prompted by specifying no (`n`). 1. FIX: We've reduced the time it takes to deploy a large set of metadata using `force:source:deploy`. ## 46.14.0 (September 12, 2019) We aren't releasing a Salesforce CLI patch this week. ## 46.13.0 (September 5, 2019) 1. FIX: You can use `force:source:deploy` to deploy SharingRules metadata. ## 46.12.1 (August 28, 2019) **Note:** The `force:auth:device:login` command is in beta and has been released early so we can collect your feedback. It may contain significant problems, undergo major changes, or be discontinued. If you encounter any problems, or want to request an enhancement, open a [GitHub issue](https://github.com/forcedotcom/salesforcedx-vscode/issues/new). The use of this feature is governed by the [Salesforce.com Program Agreement](https://trailblazer.me/resource/documents/documents/pdf/TermsOfUse_en_US.pdf). 1. NEW: Source tracking is supported for Einstein Bots metadata in scratch orgs. You can now track changes and sync source between your local DX project and scratch orgs using `source:status`, `source:push`, and `source:pull`. 1. NEW: The `force:auth:device:login` command (beta) authorizes an org using a device code. This means that you can use Salesforce CLI to authenticate in a Docker container or any headless environment without setting up JWT. For more information, see [OAuth 2.0 Device Authentication Flow](https://help.salesforce.com/articleView?id=remoteaccess_oauth_device_flow.htm&type=5) in Salesforce Help or [Remote Development](https://forcedotcom.github.io/salesforcedx-vscode/articles/user-guide/remote-development) in the **Salesforce Extensions for Visual Studio Code User Guide**. 1. FIX: When running Salesforce CLI on Windows, you can use `source:push` and `source:pull` to sync Enterprise Territory Management (also known as Territory2) metadata between your local DX project and a scratch org. ## 46.11.0 (August 22, 2019) 1. FIX: We fixed some under-the-hood bugs. ## 46.10.1 (August 15, 2019) ### Install the Pre-Release Version of the CLI Would you like to get a preview of and start trying out the changes we'll be releasing in October? Install the pre-release version of `salesforcedx` v47. We'll update the [Winter '20 Salesforce CLI release notes](http://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_sf_cli_nc.htm) (available on August 19, 2019) as we add new and changed commands and parameters. ```bash sfdx plugins:install salesforcedx@pre-release ``` Make sure that you have the pre-release version. ```bash sfdx plugins --core salesforcedx 47.0.1-xx ``` When we officially release v47 on October 12, 2019, uninstall the pre-release, then update the CLI. ```bash sfdx plugins:uninstall salesforcedx sfdx update ``` ### This Week's CLI Changes for 46.10.1 1. FIX: You can use the same name for a Salesforce DX project and Lightning web component. 1. FIX: The `--wait` parameter now works correctly when running `force:org:create`. 1. FIX: On Windows, the `force:source:deploy -x` command deploys the Folder metadata type. 1. FIX: The `force:source:pull` command recognizes when you delete a custom field on a standard object, and deletes the custom field in your local project. ## 46.9.0 (August 8, 2019) 1. CHANGE: The CLI's autoupdate functionality isn't currently working. To get new versions of Salesforce CLI and the `salesforcedx` plug-in, run: ```bash sfdx update ``` 1. FIX: When working with reports and dashboards in folders that are within other report and dashboard folders, you can now run `source:push`, `source:pull`, `source:deploy`, `source:retrieve`, and `source:convert` successfully. 1. FIX: The `force:mdapi:convert` command now works for Lightning web components. ## 46.8.0 (August 1, 2019) We aren't releasing a Salesforce CLI patch this week. (We expect the changes that were previously listed as going out on August 1, 2019, to go out on August 8, 2019.) ## 46.7.0 (July 25, 2019) We aren't releasing a Salesforce CLI patch this week. ## 46.6.0 (July 18, 2019) 1. NEW: You can delete a sandbox created by the CLI. Previously, you could delete only scratch orgs using this command. ```bash sfdx force:org:delete -u MyDevSandbox ``` **Warning:** We don't provide a prompt when you delete a sandbox, but we plan to add that functionality in a future release. ## 46.5.0 (July 11, 2019) We aren't releasing a Salesforce CLI patch this week. ## 46.4.0 (July 3, 2019) 1. FIX: The @salesforce/core library (`AuthInfo.getSfdxAuthUrl`) returned the incorrect SFDX auth URL. It now returns the same SFDX auth URL as the `force:org:display --verbose` command. ## 46.3.0 (June 27, 2019) 1. FIX: We fixed some under-the-hood bugs. ## 46.2.3 (June 20, 2019) 1. FIX: The `force:source:deploy` command once again displays specific information if a deployment fails instead of a generic error message. ## 46.1.5 (June 15, 2019) Welcome to the first release of version 46 of the `salesforcedx` plug-in for Salesforce CLI in Summer '19. Here's what's changed. ### Installation Notes We're still working on creating `salesforcedx` v46 installers. However, you can easily update Salesforce CLI to v46 by running `sfdx update` or any CLI command. If you are installing Salesforce CLI for the first time, see [Install Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli) to install the CLI for your operating system, then run `sfdx update`. ### Uninstall the Pre-Release Version of the `salesforcedx` CLI Plug-In If you installed the pre-release version 46 of the `salesforcedx` plug-in, uninstall it, then run the update command. ```bash sfdx plugins:uninstall salesforcedx sfdx update ``` ### New Commands These new commands are available in `salesforcedx` v46. * `force:package:hammertest:list` (Pilot): Lists the statuses of running and completed ISV Hammer tests. * `force:package:hammertest:report` (Pilot): Returns the status of a running ISV Hammer test or the results of a completed hammer test. * `force:package:hammertest:run` (Pilot): Runs ISV Hammer for the specified package version and subscriber orgs. * `force:org:clone` (Beta): Clones a sandbox org using values specified in a configuration file or key=value pairs that you specify on the command line. Values specified on the command line override values in the configuration file. * `force:org:status` (Beta): Reports sandbox org creation status. If the org is ready, authenticates to the org. * `force:source:deploy:cancel`: Cancels a source deployment. If you include `--wait 0`, it runs the command asychronously and immediately returns the job ID. * `force:source:deploy:report`: Checks the status of a source deployment. If you don't supply a job ID, returns the status of the most recent deployment job. * `force:source:retrieve:report`: Checks the status of a source retrieval. If you don't supply a job ID, returns the status of the most recent retrieval job. ### New Parameters These parameters are new in `salesforcedx` v46. `force:org:create --type | -t`: The type of org to create. If a parameter isn't provided, the default is a scratch org. Use sandbox to create a sandbox org (available as a beta release). Provide sandbox properties (see the SandboxInfo object) as key=value pairs or in a sandbox org definition file. This command references a definition file. ```bash sfdx force:org:create -t sandbox -f config/mysbxconfig.json ``` Here's what the sandbox org definition JSON file mysbxconfig.json looks like. ```json { "sandboxName": "MySandbox", "licenseType": "Developer" } ``` * `force:org:create --targetusername | -u`: A username for the production org to receive the sandbox request (available as a beta release). If a parameter isn't provided, the defaultusername value is used. * `force:package:install --apexcompile | -a`: For unlocked packages only, specifies whether to compile all Apex in the org and package (`--apexcompile all`), or only the Apex in the package (`--apexcompile package`). * `force:source:deploy`: We added several parameters to make this command consistent with `mdapi:deploy`.
          ParameterDescription
          `--checkonly` (`-c`)Validates the deployed metadata and runs all Apex tests, but prevents the deployment from being saved to the org.
          `--ignoreerrors` (`-o`)Ignores the deploy errors, and continues with the deploy operation. The default is false. Keep this parameter set to false when deploying to a production org. If set to true, components without errors are deployed, and components with errors are skipped.
          `--ignorewarnings` (`-g`)If a warning occurs and `--ignorewarnings` is set to true, the success field in DeployMessage is true. When `--ignorewarnings` is set to false, success is set to false, and the warning is treated like an error.
          `--runtests` (`-r`) `RUNTESTS`Lists the Apex classes containing the deployment tests to run. Use this parameter when you set `--testlevel` to `RunSpecifiedTests`.
          `--testlevel` (`-l`) `TESTLEVEL`Specifies which level of deployment tests to run. Valid values are `NoTestRun`, `RunSpecifiedTests`, `RunLocalTests`, and `RunAllTestsInOrg`.
          `--validatedeployrequestid` (`-q`) `REQUESTID`Deploys a recently validated set of metadata without the need to rerun the tests.
          `--verbose`Indicates that you want verbose output from the deploy operation.
          * `force:source:retrieve`: We added several parameters to make this command consistent with `mdapi:retrieve`.
          ParameterDescription
          `--apiversion` (`-a`) `APIVERSION`Use to override the default, which is the latest version supported by your CLI plug-in.
          `--packagenames` (`-n`) `PACKAGENAMES`A comma-separated list of package names to retrieve. You can use this parameter with other parameters to determine the complete set of metadata to retrieve. You can specify `--packagenames` as the only scoping parameter, or you can specify both `--packagenames` and one of the other scoping parameters: `--metadata`, `--sourcepath`, or `--manifest`.
          `--verbose`Indicates that you want verbose output from the retrieve operation.
          ### Changed Parameters This parameter has changed in `salesforcedx` v46. * `force:package:install --upgradetype | -t`: This parameter has a new permissible value: `Delete`. For package upgrades, this parameter specifies whether to mark all removed components as deprecated (`--upgradetype DeprecateOnly`), to delete removed components that can be safely deleted and deprecate the others (`--upgradetype Mixed`), or to delete all removed components, except for custom objects and custom fields, that don't have dependencies (`--upgradetype Delete`). ### Deprecated Parameters These parameters, which were previously marked as deprecated, were removed in `salesforcedx` v46.
          CommandDeprecated Parameters
          `force:mdapi:deploy``--jobid` (`-i`); Use `sfdx force:mdapi:deploy:report -i` **jobId** instead
          `force:mdapi:deploy``--rollbackonerror` (`-e`); Use `--ignoreerrors` (`-o`) instead
          ================================================ FILE: releasenotes/sfdx/v47.md ================================================ # Salesforce CLI v47 Release Notes Here are the new and changed features in recent updates of Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. [Click here for the v46 release notes.](./v46.md) ## 47.18.0 (February 6, 2020) 1. FIX: We fixed various issues with the progress bar that displays when you run `force:source:deploy`, `force:source:push`, or `force:mdapi:deploy`. The progress bar now outputs to `stderr` instead of `stdout`. You can remove the progress bar and instead see a readout of progress using either method: 1. To set globally, use the environment variable: `SFDX_USE_PROGRESS_BAR=false`. 1. To set for a single command: `SFDX_USE_PROGRESS_BAR=false sfdx force:source:deploy`. ## 47.17.0 (January 30, 2020) 1. FIX: We fixed some minor under-the-hood bugs. ## 47.16.0 (January 23, 2020) 1. FIX: We fixed the `MaxListenersExceededWarning` bug. 1. FIX: When running `force:project:create`, duplicate folder structures are no longer created. 1. FIX: When running `-h | --help` on the templates commands, the default value for the `outputDir` flag accurately states the current working directory. ## 47.15.0 (January 16, 2020) 1. NEW: We provide two options to opt out of telemetry. Run `force:config:set disableTelemetry=true` or set the `SFDX_DISABLE_TELEMETRY` environment variable to true. 1. FIX: When using the `-x` parameter with `force:source:retrieve`, static resources are retrieved correctly. 1. FIX: Running `force:apex:execute` with the JSON flag (--json) displays the correct output. ## 47.14.0 (January 9, 2020) 1. NEW: When running `force:mdapi:deploy`, `force:source:deploy`, or `force:source:push`, we display a progress bar to highlight the start and completion of the command. 1. NEW: We've added a `--checkonly | -c` parameter to the `force:source:delete` command. This parameter allows you to validate your `source:delete` before deleting metadata. 1. NEW: We've released a new autocomplete feature. Once installed, you can type a command and then press Tab to autocomplete a partially typed command, or press Tab to see all the available commands. If there are no matching commands or parameters to return, pressing Tab autocompletes the file path in your current directory. **Note**: Autocomplete is not currently available on Windows. To install this feature, follow these steps: 1. Make sure you're on the latest version of the CLI. 1. Run `sfdx plugins:install @oclif/plugin-autocomplete`. 1. Run `sfdx autocomplete`, then follow the displayed instructions. 1. NEW: We've added a new command, `force:analytics:template:create`, which allows you to create a simple analytics template in a specified directory. 1. CHANGE: Commands run against a scratch org complete successfully regardless of the location of the JWT key file (server.key) used to authorize the Dev Hub org. 1. FIX: Running `force:apex:test:run` with or without a JWT key file (server.key) works as expected. 1. FIX: When updating the CLI to the latest version, you no longer see a `MaxListernersExceededWarning` message. 1. FIX: When running `force:source:deploy`, static resource zip files are automatically deleted from the temp directory. ## 47.13.0 (January 2, 2020) We aren't releasing a Salesforce CLI patch this week. ## 47.12.0 (December 26, 2019) We aren't releasing a Salesforce CLI patch this week. ## 47.11.0 (December 19, 2019) We aren't releasing a Salesforce CLI patch this week. ## 47.10.9 (December 12, 2019) 1. FIX: When running `force:source:deploy`, you can specify the name of a CustomLabel within the package manifest. 1. FIX: The `force:config:set` command displays the correct error message in Salesforce Extensions for VS Code. ## 47.9.0 (December 5, 2019) 1. FIX: When running `force:mdapi:convert --metadata`, you can now pass a comma-separated list of metadata types. ## 47.8.0 (November 28, 2019) We aren't releasing a Salesforce CLI patch this week. ## 47.7.0 (November 21, 2019) We aren't releasing a Salesforce CLI patch this week. ## 47.6.2 (November 14, 2019) 1. NEW: We added SOQL and Apex files to the standard template for a DX project when you run `sfdx force:project:create`. 1. CHANGE: When you create a project, the `sourceApiVersion` in the `sfdx-project.json` file is now the same as the CLI version. 1. FIX: We made some updates to the `salesforcedx-templates` to address security issues. 1. FIX: The `--componentname` parameter for the `lightning:app:create` and `visualforce:component:create` commands follows the Lightning web component naming conventions. It uses lower camel case for component file names and upper camel case for JavaScript class names. 1. FIX: The `sfdx force:source:pull` command supports the Workflow metadata type. ## 47.5.0 (November 7, 2019) 1. FIX: We made some updates to the JSforce library to address security issues. 1. FIX: When running `force:project:create`, project names can include special characters. To use a reserved character in the project name, surround the project name in quotation marks: ```bash sfdx force:project:create -n "test&project" sfdx force:project:create -n "\\testproject?" ``` ## 47.4.0 (October 31, 2019) 1. CHANGE: Due to framework changes in the `salesforcedx` plug-in, the `-a` short version of the `--apiversion` parameter is no longer available for these commands: 1. `force:apex:class:create` 1. `force:apex:trigger:create` 1. `force:lightning:app:create` 1. `force:lightning:component:create` 1. `force:lightning:event:create` 1. `force:lightning:interface:create` 1. `force:visualforce:component:create` 1. `force:visualforce:page:create` 1. FIX: When an alias for a username exists, running `force:auth:list` displays the username and the alias. If no alias exists, the command returns only the username. 1. FIX: When deploying metadata to an org, running `force:mdapi:deploy` with the `validateddeployrequestid` option now completes without errors. ## 47.3.7 (October 24, 2019) 1. CHANGE: We've added new parameters to the `force:source:convert` and `force:mdapi:convert` commands: `-x | --manifest`, `-m | --metadata`, and `-p | --sourcepath`. 1. FIX: OrgPreferenceSettings now work again when creating a scratch org. See the [Metadata API Guide](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_orgpreferencesettings.htm) for a full list of deprecated OrgPreferenceSettings. You'll need to update your scratch org definition to use the associated Setting when Spring '20 (CLI v48) releases. ## 47.2.0 (October 17, 2019) We didn't release a CLI patch this week. ## 47.1.5 (October 10, 2019) Welcome to the first release of version 47 of the `salesforcedx` plug-in for Salesforce CLI in Winter '20. Here's what's changed: 1. FIX: When the `force:org:create` command encounters signup errors, Salesforce CLI no longer hangs. 1. FIX: When the `force:org:create` command encounters problems with streaming, it fails over to the polling client, and the command timeout default (or the `--wait` parameter value) is now honored. 1. FIX: When deploying ExperienceBundle metadata, `source:pull` and `source:status` recognize the remote changes. 1. FIX: When running Salesforce CLI on Windows, run either `sfdx force:source:retrieve -x package.xml` or `sfdx force:source:retrieve -m Dashboard:Dashboard_Folder/Dashboard_Name` to retrieve your dashboard. If you plan to retrieve using a manifest, make sure to add dashboards to your `package.xml`. 1. FIX: Running `force:source:delete` deletes an entire directory. To delete an individual file, delete it from your local DX project, then use `force:source:push` (for scratch orgs) or `force:source:deploy` to update the static resource in the target org. 1. CHANGE: The S1DesktopEnabled setting is automatically enabled when you create a scratch org. We removed the setting from the sample scratch org definition file when you create a project using `force:project:create`. ### Installation Notes We're still working on creating `salesforcedx` v47 installers. However, you can easily update Salesforce CLI to v47 by running `sfdx update` or any CLI command. If you are installing Salesforce CLI for the first time, see [Install Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli) to install the CLI for your operating system, then run `sfdx update`. ### Uninstall the Pre-Release Version of the `salesforcedx` CLI Plug-In If you installed the pre-release version 47 of the `salesforcedx` plug-in, uninstall it, then run the update command. ```bash sfdx plugins:uninstall salesforcedx sfdx update ``` ### ISV Hammer Commands Now in Beta These new commands are now available in `salesforcedx` v47 (beta). * `force:package:hammertest:list`: Lists the statuses of running and completed ISV Hammer tests. * `force:package:hammertest:report`: Returns the status of a running ISV Hammer test or the results of a completed hammer test. * `force:package:hammertest:run`: Runs ISV Hammer for the specified package version and subscriber orgs. **Note**: As a beta feature, ISV Hammer is a preview and isn’t part of the “Services” under your master subscription agreement with Salesforce. Use this feature at your sole discretion, and make your purchase decisions only on the basis of generally available products and features. Salesforce doesn’t guarantee general availability of this feature within any particular time frame or at all, and we can discontinue it at any time. This feature is for evaluation purposes only, not for production use. It’s offered as is and isn’t supported, and Salesforce has no liability for any harm or damage arising out of or in connection with it. All restrictions, Salesforce reservation of rights, obligations concerning the Services, and terms for related Non-Salesforce Applications and Content apply equally to your use of this feature. You can provide feedback and suggestions for this feature in the ISV Hammer group in the [Trailblazer Community](https://success.salesforce.com/loginswitcher?startURL=%2F_ui%2Fcore%2Fchatter%2Fgroups%2FGroupProfilePage%3Fg%3D0F93A000000DN6T). ### New Commands These new commands are available in `salesforcedx` v47. * `force:auth:device:login`(beta). You can authorize an org using a device code. This means that you can use Salesforce CLI to authenticate in a Docker container or any headless environment without setting up JWT. For more information, see [OAuth 2.0 Device Authentication Flow](https://help.salesforce.com/articleView?id=remoteaccess_oauth_device_flow.htm&type=5) in Salesforce Help or [Remote Development](https://developer.salesforce.com/tools/vscode/articles/user-guide/remote-development) in the **Salesforce Extensions for Visual Studio Code User Guide**. **Note**: The `force:auth:device:login` command is in beta and has been released early so we can collect your feedback. It may contain significant problems, undergo major changes, or be discontinued. If you encounter any problems, or want to request an enhancement, open a [GitHub issue](https://github.com/login?return_to=https%3A%2F%2Fgithub.com%2Fforcedotcom%2Fsalesforcedx-vscode%2Fissues%2Fnew). The use of this feature is governed by the [Salesforce.com Program Agreement](https://trailblazer.me/resource/documents/documents/pdf/TermsOfUse_en_US.pdf). ### New Parameters These parameters are new in `salesforcedx` v47. * `force:package:hammertest:run --apextestinterface | -n` (beta). After upgrade validation, runs the Apex tests in the subscriber org that implement this interface. * `force:package:version:create`. We added several parameters to this command:
          ParameterDescription
          `--codecoverage`Calculates and stores the code coverage percentage by running the Apex tests included in the package version. To promote a new managed package version to the released state, the code coverage minimum must be met.
          `--postinstallscript`For managed packages only, specifies an Apex script to run automatically in the subscriber org after the managed package is installed or upgraded.
          `--postinstallurl`Specifies a URL to post-install instructions for subscribers.
          `--releasenotesurl`Specifies a URL to release notes.
          `--uninstallscript`For managed packages only, specifies an Apex script to run automatically in the subscriber org before the managed package is uninstalled.
          ### Changed Commands The functionality for these commands changed in weekly releases of `salesforcedx` v46 or in the pre-release of v47. * `force:org:delete -u MyDevSandbox`. Deleting a sandbox created by the CLI is now supported. * `force:package:install --securitytype | -s`. We changed the default value changed from AllUsers to AdminsOnly. * `force:source:status`, `force:source:push`, `force:source:pull`. Source tracking is supported for Einstein Bots metadata in scratch orgs. ================================================ FILE: releasenotes/sfdx/v48.md ================================================ # Salesforce CLI v48 Release Notes Here are the new and changed features in recent updates of Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. If you use [autocomplete](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_cli_autocomplete.htm), run `sfdx autocomplete --refresh-cache` after you update the `salesforcedx` plug-in to ensure that autocomplete works correctly on any new commands. [Click here for the v47 release notes.](./v47.md) ## 48.22.11 (July 15, 2020) * FIX: We fixed a regression with source tracking for projects with bundled metadata types. ([GitHub issue #480 ](../../../issues/480 )) * CHANGE: We've upgraded the CLI's version of Node.js to 12.13.0. ## 48.22.8 (July 14, 2020) * FIX: We fixed a regression with multiple package directory listings in `sfdx-project.json` that point to the same path. ([GitHub issue #468 ](../../../issues/468 )) * FIX: We fixed a regression with running `force:mdapi:convert` with `--outputdir`. ([GitHub issue #471 ](../../../issues/471 )) ## 48.22.4 (July 12, 2020) * FIX: We fixed a regression with `force:source:deploy` using the `--json` and `--wait 0` parameters returning the wrong type. ([GitHub issue #472](../../../issues/472)) ## 48.22.2 (July 9, 2020) * NEW: We introduced two new commands to override how the CLI tracks your local source code. The commands work with any org that supports source tracking. * `force:source:tracking:reset`. Resets local and remote source tracking so that the CLI doesn't register current differences between your local files and metadata in the org. When you next run `force:source:status`, the CLI returns no results, even if conflicts actually exist. The CLI then resumes tracking new source changes as usual. The main use case is when the CLI doesn't have any tracking history for an org. For example, you want to use an org that's pre-populated by an automated process with the same metadata that's in your VCS. Run this command to make the CLI behave as if the local and remote files are the same at the moment you run the command. * `force:source:tracking:clear`. Clears all local source tracking information. When you next run `force:source:status`, the CLI displays all local and remote files as changed, and any files with the same name are listed as conflicts. You manually resolve these conflicts yourself by, for example, forcing a push or pull. The CLI then resumes tracking new source changes as usual. Salesforce Customer Support uses this command to diagnose issues. We don't recommend using this command in your normal work flow. **WARNING**: These commands delete or modify all existing local source tracking files in your project and affect subsequent behavior of the `force:source` commands. For example, if you reset source tracking then run `force:source:pull`, the CLI can silently overwrite local files even if there's actually a conflict. Use the commands only if you understand the differences between your local source files and the metadata in your org. And use extreme caution. Really. * CHANGE: You can use the `force:source:push` and `force:source:pull` commands on metadata files stored in multiple package directories instead of just the default package directory. Multiple package directories help you organize your local source code into logical units. ([GitHub issue #379](../../../issues/379)) Each package directory must adhere to the standard [Salesforce DX project structure](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm). List the package directories in your `sfdx-project.json` file in the order you want the packaged metadata deployed to your org. Documentation about working with multiple package directories will be available in the [Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_workspace_setup.htm) around July 15, 2020. * CHANGE: We've improved the output of the `commands` command. By default, the command displays the full list of CLI commands and their descriptions in table format. With the new parameters, you can display more columns, such as command usage and the plug-in it belongs to. You have more choices for the output format (`.csv`, `.json`, `.yaml`). You can also filter and sort the output. The `commands` command works the same as the [oclif command](https://github.com/oclif/plugin-commands#oclif-example-commands). * FIX: You can run `force:source:push` after deleting a report that begins with the letter D in an org. Previously the push returned an error such as `ERROR running force:source:push: SourceMember WHERE MemberName IN ('unfiled$public\Demo_time_per_lead_1Yb'`. ([GitHub issue #221](../../../issues/221)) ## 48.21.0 (July 2, 2020) * We aren't releasing a Salesforce CLI patch this week. ## 48.20.0 (June 25, 2020) * We aren't releasing a Salesforce CLI patch this week. * As we described in this [blog post](https://developer.salesforce.com/blogs/2020/05/open-sourcing-salesforce-cli.html), we've open-sourced the Salesforce CLI release notes and moved them to this GitHub repository. Join us at [TrailheadDX 2020](https://www.salesforce.com/trailheadx/) to find out what's new in Salesforce developer tooling. ## 48.19.0 (June 18, 2020) * FIX: We fixed some under-the-hood bugs. ## 48.18.1 (June 11, 2020) * NEW: We introduced a new topic (`cmdt`) and five new commands in this topic for managing custom metadata types. * `force:cmdt:create`. Creates a custom metadata type in the current project. * `force:cmdt:field:create`. Generates a custom metadata field based on the provided field type. * `force:cmdt:generate`. Generates a custom metadata type and all its records for the provided sObject. * `force:cmdt:record:create`. Creates a record for a given custom metadata type in the current project. * `force:cmdt:record:insert`. Creates custom metadata type records from a comma-separated values (CSV) file. To learn more about custom metadata types, read our [documentation](https://help.salesforce.com/articleView?id=custommetadatatypes_overview.htm). ## 48.17.0 (June 4, 2020) * FIX: We've improved the error message when running `force:source:deploy` and your manifest file (`package.xml`) contains an incorrect entry for the Workflow or WorkflowFieldUpdate metadata type. An example of an incorrect entry is a reference to a local file that doesn't exist. The command now prompts you to review your `package.xml` file for user errors. Previously it returned the error `RangeError: Maximum call stack size exceeded`. ([GitHub issue #280](https://github.com/forcedotcom/cli/issues/280)) ## 48.16.2 (May 28, 2020) * FIX: The ExperienceBundle metadata type works correctly when running `force:mdapi:convert`. The [E-Bikes Lightning Web Components Sample Application](https://github.com/trailheadapps/ebikes-lwc) no longer throws this error: ```bash ERROR running force:mdapi:convert: Expected content file(s) at path(s): /Users/jdoe/sfdx/ebikes-lwc/converted/experiences/E_Bikes1.site ``` * FIX: The `force:org:list` command displays correct information immediately after you run `force:org:create` to create a scratch org. In particular, we display correct alias information and no longer display refresh tokens. * FIX: The `force:user:display` command correctly displays the user's plain text password rather than its hashed value. ([GitHub issue #417](https://github.com/forcedotcom/cli/issues/417)) ## 48.15.0 (May 21, 2020) * CHANGE: We aren't able to calculate code coverage for the `force:package:version:list` and `force:package:version:report` commands. We're working on a fix and will tell you when that feature is available again. ## 48.14.3 (May 14, 2020) * FIX: We've standardized character encoding across the `force:mdapi:retrieve` and `force:source:retrieve` results sets. You'll now see apostrophes displayed as `&apos`. * FIX: Running `force:user:display -u | --targetusername` automatically refreshes an expired token and displays a new one. * FIX: Running `force:data:record:update -t | --usetoolingapi` successfully updates the record. ## 48.13.1 (May 7, 2020) * FIX: The `force:org:list` command no longer throws unexpected errors. ## 48.12.0 (April 30, 2020) * NEW: We added a parameter, `--skipconnectionstatus`, to the `force:org:list` command. Use this parameter to remove the Connected Status column from the org list output and to improve performance. ## 48.11.0 (April 23, 2020) * We aren't releasing a Salesforce CLI patch this week. ## 48.10.1 (April 16, 2020) * FIX: We fixed some under-the-hood bugs. ## 48.9.0 (April 9, 2020) * We aren't releasing a Salesforce CLI patch this week. ## 48.8.0 (April 2, 2020) * FIX: We fixed some under-the-hood bugs. ## 48.7.0 (March 26, 2020) * FIX: We fixed some under-the-hood bugs. ## 48.6.0 (March 19, 2020) * We aren't releasing a Salesforce CLI patch this week. ## 48.5.1 (March 12, 2020) * FIX: When running `force:data:record:update`, you can update a date field to a null value. * FIX: Apex unit test failures appear in the output when you run `force:source:deploy --testlevel`. ## 48.4.1 (March 5, 2020) * NEW: We added a `package.json` file to the standard and analytics Salesforce DX templates. To create these templates, run `force:project:create --template=standard` or `force:project:create --template=analytics`. * CHANGE: We are deprecating `force:doc:commands:list` and `force:doc:commands:display`. We will remove these commands in v49.0. Instead, run `sfdx commands`, which produces similar output. * FIX: We fixed `force:user:create --json` so it works as expected when assigning `permsets`. ## 48.3.1 (February 27, 2020) * FIX: We fixed some under-the-hood bugs. ## 48.2.0 (February 20, 2020) * NEW: We introduced three new commands to offer you Lightning Web Components test functionality. * `force:lightning:lwc:test:create`. Creates a Lightning Web Components test with boilerplate code inside a `__tests__` directory. * `force:lightning:lwc:test:setup`. Installs Jest unit testing tools for Lightning Web Components. * `force:lightning:lwc:test:run`. Invokes Lightning Web Components Jest unit tests. To learn more about testing Lightning Web Components, read our [documentation](https://developer.salesforce.com/docs/component-library/documentation/en/48.0/lwc/lwc.testing). * FIX: When deploying source with the `-c | --checkonly` flag, errors once again display to the console. ## 48.1.5 (February 18, 2020) * FIX: We fixed the `npm install sfdx-cli` error. ([Github issue #304](https://github.com/forcedotcom/cli/issues/304)). ## 48.1.4 (February 17, 2020) * FIX: Deployments to production using `force:mdapi:deploy` or `force:source:deploy` complete as expected. ([Github issue #305](https://github.com/forcedotcom/cli/issues/305)). ## 48.1.2 (February 15, 2020) Welcome to the first release of version 48 of the `salesforcedx` CLI plug-in in Spring '20. * CHANGE: Now all JSON output will be sent to `stdout`. Over a year ago we introduced an environment variable, `SFDX_JSON_TO_STDOUT`, to move all JSON output to `stdout` when `true`. This functionality is now the default. If you rely on parsing errors from `stderr` when using `--json`, update your tools and scripts to `stdout` or set `SFDX_JSON_TO_STDOUT` to `false`. You can expect more warnings and errors to be sent to `stderr` even with `--json` set. Learn more about this change in our [blog post.](https://developer.salesforce.com/blogs/2020/02/using-salesforce-cli-output-and-scripting.html?utm_campaign=February_2020&utm_source=release_notes&utm_medium=) ### Installation Notes We're still working on creating `salesforcedx` v48 installers. However, you can easily update Salesforce CLI to v48 by running `sfdx update` or any CLI command. If you are installing Salesforce CLI for the first time, see [Install Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli) to install the CLI for your operating system, then run `sfdx update`. ### Uninstall the Pre-Release Version of the `salesforcedx` CLI Plug-In If you installed the pre-release version 48 of the `salesforcedx` plug-in, uninstall it, then run the update command. ```bash sfdx plugins:uninstall salesforcedx sfdx update ``` ### New Commands * `force:analytics:template:create`. Allows you to create a simple analytics template in a specified directory. * `force:community:create`. Creates a community using a template. * `force:community:publish`. Publishes your Lightning community to make it live. Each time you publish, you update the live community with the most recent updates. * `force:community:template:list`. Retrieves the list of templates available in your org for creating a community. ### New Parameters * `force:package:version:create --skipvalidation`. Skips validation during package version creation. Skipping validation allows you to create package versions faster, but you can’t promote a package version that was created without validation. * `force:source:delete --checkonly`. Performs a test deployment (validation) in the non-sourced-tracked org without deleting the metadata. After the validation passes, you can safely delete the metadata using this command. ### Changed Commands * `force:package:version:list`. Displays columns that indicate if the package version has passed code coverage, and the code coverage percentage. We also added columns to indicate the ancestor ID and ancestor version number for the package version's ancestor. Ancestor ID and version number display for package versions created in Spring '20 and later. ### Changed Parameters These parameters were added to the `force:source:convert` and `force:mdapi:convert` commands in a weekly release of `salesforcedx`. * `-x | --manifest`. Specifies the complete path to the manifest (`package.xml`) file that specifies the metadata types to convert. * `-m | --metadata`. Specifies a comma-separated list of metadata component names to convert. * `-p | --sourcepath`. Specifies a comma-separated list of paths to the local source files to convert (`force:source:convert`). * `-p | --metadatapath`. Specifies a comma-separated list of paths to the local source files to convert (`force:mdapi:convert`). ### Deprecated Parameters We removed the `-a` short version of the `--apiversion` parameter. The following commands were affected: * `force:apex:class:create` * `force:apex:trigger:create` * `force:lightning:app:create` * `force:lightning:component:create` * `force:lightning:event:create` * `force:lightning:interface:create` * `force:visualforce:component:create` * `force:visualforce:page:create` ================================================ FILE: releasenotes/sfdx/v49.md ================================================ # Salesforce CLI v49 Release Notes Here are the new and changed features in recent updates of Salesforce CLI and the `salesforcedx` plug-in. Run `sfdx version` to display the version of Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. If you use [autocomplete](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_cli_autocomplete.htm), run `sfdx autocomplete --refresh-cache` after you update the `salesforcedx` plug-in to ensure that autocomplete works correctly on any new commands. [Click here for the v48 release notes.](./v48.md) ## 49.14.0 (October 8, 2020) We aren't releasing a Salesforce CLI patch this week. But we have a few announcements. * NEW: Want to play with the next version of Salesforce CLI before it's live? We target publicly releasing a candidate by Tuesday, although it could be anytime before Thursday, the official release day. Check [open pull requests](https://github.com/forcedotcom/cli/pulls) for early drafts of the release notes. If you find any issues or have feedback after testing, create a Github issue [here](https://github.com/forcedotcom/cli/issues) and include the release candidate version in the title. To install the early release candidate of the CLI to, for example, test that it works correctly with your CI jobs, run this command: `$ npm install sfdx-cli@latest-rc` To install the early release candidate of the `salesforcedx` plug-in to test the `force` commands using your current CLI version, run this command: `$ sfdx plugins:install salesforcedx@latest-rc` To stop getting early candidates and go back to using the `salesforcedx` plug-in version bundled with the CLI, run this command: `$ sfdx plugins:uninstall salesforcedx` * CHANGE: To improve usability and better align with how the Salesforce developer tools have evolved over time, we're reorganizing the Salesforce DX Developer and Setup Guides. In particular, we've moved most of the CLI Configuration and Tips topics to the [Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm). Next up are the Dev Hub topics, which will move to the [Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm). We’ll fix internal cross-references, but you might need to refresh your bookmarks. **TIP**: If a bookmark to one of these guides no longer works, try changing the first two `setup` parts of the URL to `dev`, or vice versa. For example, the old URL to the CLI Runtime Configuration Values topic was: `https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_cli_config_values.htm` Now it's: `https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_config_values.htm` ## 49.13.1 (October 8, 2020) * FIX: The `force:source:deploy` and `force:source:convert` commands work with custom fields when specified directly with the `-m CustomField` parameter or when bundled with other metadata with the `-x package.xml` parameter. (GitHub issues [#156](https://github.com/forcedotcom/cli/issues/156), [#542](https://github.com/forcedotcom/cli/issues/542), [#611](https://github.com/forcedotcom/cli/issues/611), [#623](https://github.com/forcedotcom/cli/issues/623), [#625](https://github.com/forcedotcom/cli/issues/625), and [#628](https://github.com/forcedotcom/cli/issues/628)) * FIX: The `force:auth` and `force:org:signup` commands correctly map new sandbox instances to the sandbox audience URL. ## 49.13.0 (October 1, 2020) * NEW: Override SourceMember polling time-outs when running the `force:source:push` command with the SFDX_SOURCE_MEMBER_POLLING_TIMEOUT environment variable. The command polls the SourceMember object to track what's changed between your local source and the org after the push completes. To prevent the command from timing out too quickly, set the environment variable to the number of seconds you want it to keep polling. There is no default value for this environment variable. The CLI calculates a time-out for each `force:source:push` command run based on the number of components it deploys. For example, if the push times out after 3 minutes, try setting a time-out of 5 minutes: `$ export SFDX_SOURCE_MEMBER_POLLING_TIMEOUT=300` ([GitHub Issue #572](https://github.com/forcedotcom/cli/issues/572)) * FIX: After running `force:source:deploy` to deploy a [shared CSS styles module](https://lwc.dev/guide/css#share-css-style-rules) with your Lightning Web Components, you can then successfully retrieve it with `force:source:retrieve`. (GitHub issues [#496](https://github.com/forcedotcom/cli/issues/496) and [#563](https://github.com/forcedotcom/cli/issues/563)) * FIX: The `force:source:deploy --sourcepath` (`-p`) command deploys source contained in the directories specified by the `-p` parameter, even when these directories aren't included in the `packageDirectories` section of `sfdx-project.json`. ([GitHub issue #622](https://github.com/forcedotcom/cli/issues/622)) * FIX: The `postdeploy` hook fires on both success and failure of the `force:source:push` and `force:source:deploy` commands. ([GitHub issue #624](https://github.com/forcedotcom/cli/issues/624)) * FIX: The `force:source:convert` and `force:source:deploy` commands correctly handle metadata types whose `inFolder` attribute is set to `true`. The commands then generate the appropriate FolderName-meta.xml file. (GitHub issues [#609](https://github.com/forcedotcom/cli/issues/609) and [#612](https://github.com/forcedotcom/cli/issues/612)) * FIX: The `force:package:version:create` and `force:org:create` commands run successfully in a project whose `sfdx-project.json` file uses the `ancestorVersion` attribute to specify a package ancestor. Previously, the following error was sometimes thrown for released package versions: `The ancestor package version [version] specified in the sfdx-project.json file hasn't been promoted and released. Release the ancestor package version before specifying it as the ancestor in a new package or patch version.` ([GitHub issue #312](https://github.com/forcedotcom/cli/issues/312)) ## 49.12.0 (September 24, 2020) * We aren't releasing a Salesforce CLI patch this week. ## 49.11.0 (September 17, 2020) * We aren't releasing a Salesforce CLI patch this week. ## 49.10.0 (September 10, 2020) * CHANGE: You can use the `force:source:deploy`, `force:source:retrieve`, and `force:source:delete` commands on metadata files stored in multiple package directories instead of just the default package directory. Multiple package directories help you organize your local source code into logical units. ([GitHub issue #379](https://github.com/forcedotcom/cli/issues/379)) Each package directory must adhere to the [standard Salesforce DX project structure](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm). List the package directories in your `sfdx-project.json` file in the order you want the packaged metadata deployed to your org. See [Multiple Package Directories](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_mpd.htm). * CHANGE: Now that the alias commands (`alias:set`, `alias:list`, `alias:unset`) are in their own [GitHub repo](https://github.com/salesforcecli/plugin-alias), they no longer show up in the `sfdx help force` output. Run `sfdx help alias` instead. The [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm) also lists the commands only in the `alias` namespace. **NOTE**: The `force:alias` commands will continue to work until we [deprecate](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/sfdx_dev_cli_deprecation.htm) them. We'll announce it ahead of time so you can prepare. * FIX: The `sfdx plugins:install` command works correctly when installing unsigned plug-ins. ([GitHub issue #592](https://github.com/forcedotcom/cli/issues/592)) * FIX: The `force:source:retrieve` command no longer returns the intermittent error `ERROR running force:source:retrieve: Cannot read property 'getWorkspaceElements' of undefined` in certain circumstances. ([GitHub issue #345](https://github.com/forcedotcom/cli/issues/345)) ## 49.9.2 (September 3, 2020) * NEW: As part of [open-sourcing Salesforce CLI](https://developer.salesforce.com/blogs/2020/05/open-sourcing-salesforce-cli.html), we've broken out the source for the alias commands (`force:alias:set` and `force:alias:list`) into their own [GitHub repo](https://github.com/salesforcecli/plugin-alias). As a result, the commands are now in the `alias` namespace, and no longer in the `force` namespace. For example: `$ sfdx alias:set myscratchorg=username@example.com` But don't worry, the current way to run the commands, such as `force:alias:set`, still works. We plan to deprecate the `force` version of the commands in the future. But for now, your existing workflow and CI/CD jobs will continue working. We've also added the `alias:unset` command to easily unset an alias. This new command is only in the `alias` namespace. `$ sfdx alias:unset myscratchorg` * NEW: Store the output of the `force:apex:log:get` command in a directory with the new `--outputdir` (`-d`) parameter. * CHANGE: Now that the config commands (`config:set`, `config:get`, `config:list`, and `config:unset`) are in their own [GitHub repo](https://github.com/salesforcecli/plugin-config), they no longer show up in the `sfdx help force` output. Run `sfdx help config` instead. The [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm) will soon list the commands only in the `config` namespace. **NOTE**: We continue to alias the `config` commands to their `force:config` equivalents. So, for example, `force:config:set` continues to work. We'll announce when we plan to deprecate the `force` versions of these commands. * CHANGE: We've removed the `--color` (`-c`) parameter of the `force:apex:log:get` command. Colors are displayed by default. * FIX: When you run the `force:mdapi:deploy` command but then cancel the deployment, the CLI now correctly returns a non-zero status to indicate that the deployment didn't succeed. Previously it returned a zero status, which incorrectly indicated that the deployment succeeded. ([GitHub issue #37](../../../issues/37)) * FIX: The `force:package:version:command` no longer fails with the error `typesArr.filter is not a function`. ([GitHub issue #594](../../../issues/594)) ## 49.8.0 (August 27, 2020) * NEW: As part of [open-sourcing Salesforce CLI](https://developer.salesforce.com/blogs/2020/05/open-sourcing-salesforce-cli.html), we’ve broken out the source for the config commands (`force:config:set`, `force:config:get`, `force:config:list`) into [their own GitHub repo](https://github.com/salesforcecli/plugin-config). As a result, the commands are now in the `config` namespace and no longer in the `force` namespace. For example: `$ sfdx config:set apiVersion=50.0` But don’t worry, the current way to run the commands, such as `force:config:set`, still works. We plan to deprecate the `force` version of the commands in the future. But for now, your existing workflow and CI/CD jobs will continue working. We’ve also added the `config:unset` command to unset a configuration value. This new command is only in the `config` namespace. `$ sfdx config:unset apiVersion` * NEW: Disable polling of your org's SourceMember object when you run the `force:source:push|pull` commands by setting the SFDX_DISABLE_SOURCE_MEMBER_POLLING environment variable to TRUE. The commands poll the SourceMember object to track what's changed between your local source and the org after the push or pull completes. If you have a large metadata deployment, however, the polling can take a while, or even time out. Sometimes you don't require source tracking at all, such as in a CI/CD job. These use cases are good candidates for setting this environment variable. The environment variable works with both scratch orgs and sandboxes. `$ export SFDX_DISABLE_SOURCE_MEMBER_POLLING=true` **WARNING**: When you disable SourceMember polling, the CLI's internal tracking of what's changed between your local source and org metadata gets out of sync. As a result, subsequent runs of the `force:source:push|pull|status` commands are unreliable, and it's up to you to synchronize your source. To reset source tracking, use the `force:source:tracking:reset` command. * CHANGE: We’ve changed the name of the [local file that prevents Salesforce CLI](https://developer.salesforce.com/blogs/2017/10/salesforce-dx-cli-plugin-update.html) from prompting you about trusting an unsigned plugin when you try to install it. The file is now called `unsignedPluginAllowList.json`, previously called `unsignedPluginWhiteList.json`. The file with the old name will continue to work for a while, but we recommend you change the name after you install this week's release. ## 49.7.0 (August 20, 2020) * FIX: We fixed more regressions related to multiple package directory listings in `sfdx-project.json` that point to the same path. ([July 14, 2020 fix](./v48.md#48228-july-14-2020), [GitHub issue #468](../../../issues/468)) ## 49.6.1 (August 13, 2020) * NEW: Increase the number of Salesforce records that a CLI command returns with the new `maxQueryLimit` config value. The default value is 10,000. For example, if your Salesforce org contains 15,000 roles, and you run `sfdx force:mdapi:listmetadata -m Role`, the command returns only 10,000 roles by default. The CLI command warns you that it hasn't returned all the records. Set the config value to see all the roles: `$ sfdx force:config:set maxQueryLimit=20000` The corresponding environment variable is SFDX_MAX_QUERY_LIMIT. * CHANGE: We've upgraded the CLI's version of Node.js to 12.18.3. * FIX: The Salesforce CLI installer works as expected on macOS Catalina (10.15) and later. Double-click the `*.pkg` file and you're off! ([Github issue #359](../../../issues/359)) ## 49.5.0 (August 6, 2020) * NEW: Create a hook to customize the behavior of some Salesforce CLI commands. A hook is a piece of code that runs at a specific lifecycle event during command execution. For example, create a hook for `force:source:push` to make IDs in source files unique after they've been converted to metadata format but before they're sent to the org. You can create hooks that trigger during these Salesforce CLI lifecycle events: * `predeploy`: After the CLI has converted your source files to Metadata API format but before it sends the files to the org. * `postdeploy`: After the CLI has sent the metadata to the org and the org has sent back a confirmation. * `preretrieve`: Before the CLI sends a request to the org to fetch files. * `postretrieve`: After the CLI has retrieved the metadata from the org. The metadata has not yet been converted to source format. * `postsourceupdate`: After the CLI has converted the files it fetched from the org to source format. * `postorgcreate`: Immediately after a new scratch org or sandbox is created. You can access the org from the hook. Salesforce also supports all the [oclif hooks](https://oclif.io/docs/hooks#lifecycle-events). Documentation about creating hooks will be available in the [Salesforce CLI Plug-In Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/) soon. * FIX: We've restored the display of code coverage data in the `force:package:version:list` and `force:package:version:report` commands. ([See v48.15.0 release note](./v48.md#48150-may-21-2020)) ## 49.4.1 (July 30, 2020) * FIX: You can pass an access token as a username (with the` -u` parameter) to the `force:user:permset:assign` and `force:user:password:generate` commands. Previously you'd get an error such as `The username was not found for scratch org `. * FIX: You can run the `force:source:push|deploy|convert` commands from subdirectories of the project directory. Previously you'd get `ERROR running force:source:deploy: Cannot read property 'path' of undefined`. ([GitHub issue #488 ](../../../issues/488 )) ## 49.3.0 (July 23, 2020) * We aren't releasing a Salesforce CLI patch this week. ## 49.2.3 (July 18, 2020) Welcome to the first release of version 49 of the `salesforcedx` CLI plug-in in Summer '20. ### Installation Notes Update Salesforce CLI to v49 by running `sfdx update` or any CLI command. ```bash $ sfdx update ``` If you are installing Salesforce CLI for the first time, see [Install Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli) to install the CLI for your operating system, then run `sfdx update`. Run `sfdx version` to display the version of Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. ```bash $ sfdx plugins --core @oclif/plugin-autocomplete 0.1.5 (core) @oclif/plugin-commands 1.3.0 (core) @oclif/plugin-help 3.0.1 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.7.10 (core) @oclif/plugin-update 1.3.10 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-trust 3.0.7 (core) analytics 1.12.0 (core) generator 1.1.3 (core) salesforcedx 49.2.3 // salesforcedx plug-in version ├─ salesforcedx-templates 48.32.0 ├─ custom-metadata 1.0.7 ├─ salesforce-alm 49.3.0 └─ @salesforce/sfdx-plugin-lwc-test 0.1.7 sfdx-cli 7.66.2 (core) // CLI version ``` ### Uninstall the Pre-Release Version of the salesforcedx CLI Plug-In If you installed the pre-release version of the `salesforcedx` v49 plug-in to test the next version of Salesforce CLI, uninstall it and update the CLI. We’re no longer updating the pre-release v49 plug-in. ```bash $ sfdx plugins:uninstall salesforcedx $ sfdx update ``` ### New Parameter * `force:package:create --orgdependent` (beta) For unlocked packages only, allows the package to depend on unpackaged metadata in the installation org. **Note**: As a beta feature, Org-Dependent Unlocked Packages is a preview and isn’t part of the “Services” under your master subscription agreement with Salesforce. Use this feature at your sole discretion, and make your purchase decisions only on the basis of generally available products and features. Salesforce doesn’t guarantee general availability of this feature within any particular time frame or at all, and we can discontinue it at any time. This feature is for evaluation purposes only, not for production use. It’s offered as is and isn’t supported, and Salesforce has no liability for any harm or damage arising out of or in connection with it. All restrictions, Salesforce reservation of rights, obligations concerning the Services, and terms for related Non-Salesforce Applications and Content apply equally to your use of this feature. You can provide feedback and suggestions for Org-Dependent Unlocked Packages in the [Trailblazer Community](https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000Lg5USAS). ### Deprecated Commands These commands are deprecated in v49. Use the `force:lightning:lwc:test:*` commands instead. * `force:lightning:test:create` * `force:lightning:test:install` * `force:lightning:test:run` These commands continue to be deprecated in v49; they were first deprecated in v48 and will be removed in a future release. Use `sfdx commands` instead, which produces similar output. * `force:doc:commands:list` * `force:doc:commands:display` ## Other Changes * We've upgraded the CLI's version of Node.js to 12.13.0. * The `force:org:clone` and `force:org:status` sandbox CLI commands are generally available. The commands were beta in v48. ================================================ FILE: releasenotes/sfdx/v50.md ================================================ # Salesforce CLI v50 Release Notes Here are the new and changed features in recent updates of Salesforce CLI and the `salesforcedx` plug-in. We publish the `latest` plug-in and CLI on Thursdays. At the same time we also publish the `latest-rc` release candidate plug-in and CLI. The release candidates contain changes that will likely be in the final official version. Run `sfdx version` to display the version of Salesforce CLI installed on your computer. Run `sfdx plugins --core` to display the version of the installed `salesforcedx` plug-in. Run `sfdx update` to update both the CLI and the `salesforcedx` plug-in to the latest available version. If you use [autocomplete](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_autocomplete.htm), run `sfdx autocomplete --refresh-cache` after you update the `salesforcedx` plug-in to ensure that autocomplete works correctly on any new commands. [Click here for the v49 release notes.](./v49.md) ## February 11, 2021 These changes are in the release candidate plug-in (`salesforcedx@latest-rc`). We plan to include these changes in the next official release. This list isn't final and is subject to change. * NEW: Use the SFDX_DNS_TIMEOUT environment variable to configure how long the `force:org` commands wait for a response when checking if an org is connected. Set the variable to the number of seconds before the commands time out. Default value is 3. * FIX: We've improved the error message returned when you run `force:user:password:generate` using API version 51.0 and EnableSetPasswordInApi is configured as a security setting in your scratch org definition file. EnableSetPasswordInApi is now a scratch org feature instead of a Metadata API setting. Here's an example of configuring it as a feature in your scratch org definition file: `"features": ["EnableSetPasswordInApi","MultiCurrency"],` This change is a result of the field `Settings.securitySettings.passwordPolicies.enableSetPasswordInApi` being [removed in version 51.0 of the Metadata API](https://help.salesforce.com/articleView?id=release-notes.rn_api_meta.htm&type=5&release=230). (GitHub issue [#798](https://github.com/forcedotcom/cli/issues/798)) ## 7.86.3 (February 5, 2021) - (salesforcedx 50.16.1) **NOTE**: This release also includes the changes in the [50.13.3 (January 14, 2021)](./README.md#50133-january-14-2021---cli-7842) release that we rolled back. * FIX: We've improved the message returned when you delete a sandbox with `force:org:delete`. The new message clarifies that sandboxes created with `force:org:create|clone` are marked for deletion. (GitHub issue [#769](https://github.com/forcedotcom/cli/issues/769)) ## January 28, 2021 * We aren't releasing a Salesforce CLI patch this week. ## January 21, 2021 * We aren't releasing a Salesforce CLI patch this week. ## 7.84.2 (ROLLED BACK - January 14, 2021) - (salesforcedx 50.13.3) **NOTE**: We rolled back this release on January 15, 2021. See [this announcement](https://github.com/forcedotcom/cli/issues/811) for details. The changes in this release will be included in the next release. * NEW: Create a static resource in your local project directory with the `force:staticresource:create` command. Examples of static resources include code libraries in a ZIP file, images, JSON files, and style sheets. The default content type (mime type) is `application/zip`; use the `--contenttype` parameter to specify a different content type, such as `application/json`. The command generates the `MyResource.resource-meta.xml` file in the current directory; use `-d | --outputdir` to generate it in a different directory. Static resources must reside in the `main/default/staticresources` directory under your package directory. For example: ```bash $ cd myprojectdir/force-app $ sfdx force:staticresource:create -n MyResource --contenttype application/json -d main/default/staticresources ``` * CHANGE: Now that the `auth` commands (such as `force:auth:jwt:grant` and `force:auth:web:login`) are in their own [GitHub repo](https://github.com/salesforcecli/plugin-auth), they no longer show up in the `sfdx help force` output. Run `sfdx help auth` instead. The [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm) will soon list these commands in only the `auth` namespace. We continue to alias the `auth` commands to their `force:auth` equivalents. So, for example, `force:auth:jwt:grant` continues to work. We'll announce when we plan to deprecate the `force` versions of these commands. We’ll then follow our standard deprecation policy, which gives you ample time to update your scripts. * CHANGE: We [deprecated](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_deprecation.htm) the `force:source:project:upgrade` command. The command upgrades files between old CLI releases and its functionality is no longer needed. * FIX: The `force:source:retrieve -n ` command retrieves custom object subcomponents, such as custom fields. Previously the command retrieved just the custom object itself. (GitHub issue [#644](https://github.com/forcedotcom/cli/issues/644)) * FIX: The `force:source:pull` command correctly retrieves static resources after you've updated them in the Salesforce user interface. * FIX: Commands whose `-u` parameter accepts an access token as a value, in addition to a username, are working correctly. An example is `force:user:password:generate`. Previously you'd get an error such as `The username was not found for scratch org 00D…` (GitHub issue [#290](https://github.com/forcedotcom/cli/issues/290)) * FIX: The `force:source:retrieve|pull -m "CustomObject:MyCustomObject__c"` commands correctly retrieve a field whose name is the same as the custom object itself. (GitHub issue [#579](https://github.com/forcedotcom/cli/issues/579)) * FIX: We've updated the CLI to use the [graceful-fs npm package](https://www.npmjs.com/package/graceful-fs). As a result, the CLI can process a lot more files, and some errors no longer occur. Previously, for example, you sometimes got the error `EMFILE: too many open files` when running `force:source:convert` on Windows. * FIX: The `auth:jwt:grant` command correctly authenticates on Windows. Previously, if you installed or upgraded the CLI on Windows using npm, you’d get the error message `ERROR running auth:jwt:grant: We encountered a JSON web token error, which is likely not an issue with Salesforce CLI.` (GitHub issue [#757](https://github.com/forcedotcom/cli/issues/757)) * FIX: The `force:source:retrieve|pull -m "MutingPermissionSet:Name"` commands correctly retrieve muting permission sets. Previously you'd get the error message `ERROR running force:source:retrieve: "cannot read property 'metadataName' of undefined"`. (GitHub issue [#339](https://github.com/forcedotcom/cli/issues/339)) ## January 7, 2021 * We aren't releasing a Salesforce CLI patch this week. ## December 10, 17, 24, and 31, 2020 * We aren't releasing a Salesforce CLI patch on any of these weeks. Have a happy and safe holiday season. ## 7.82.1 (December 3, 2020) - (salesforcedx 50.7.1) * FIX: We’ve removed the CLI’s dependency on [ANTLR](https://www.antlr.org/). (GitHub issues [#746](https://github.com/forcedotcom/cli/issues/746) and [#754](https://github.com/forcedotcom/cli/issues/754)) ## November 26, 2020 * We aren't releasing a Salesforce CLI patch this week. Have a happy and safe Thanksgiving! ## 7.81.0 (November 19, 2020) - (salesforcedx 50.6.0) * FIX: The `force:source:push|pull|status|deploy|retrieve` commands work with duplicate rules. Previously you'd get the message `No results found` and the rule wouldn't be recognized by the `source` commands. (GitHub issue [#685](https://github.com/forcedotcom/cli/issues/685)) * FIX: The `force:source:retrieve` and `force:mdapi:convert -m ` commands work with [Lightning Web Component CSS style components](https://lwc.dev/guide/css). Previously you’d get the error `ERROR running force:mdapi:convert: Cannot read property 'fileName' of undefined`. Also, for `force:source:retrieve`, the metadata files weren't being copied to their proper location in the project. (GitHub issues [#496](https://github.com/forcedotcom/cli/issues/496), [#563](https://github.com/forcedotcom/cli/issues/563), and [#655](https://github.com/forcedotcom/cli/issues/655)) ## 7.80.0 (November 12, 2020) (salesforcedx 50.5.0) * CHANGE: The `force:apex:log:list` command displays results in descending order. Previously it displayed results in ascending order. (Salesforce Extensions for VS Code GitHub issue [#2698](https://github.com/forcedotcom/salesforcedx-vscode/issues/2698)) * FIX: The `force:source:convert` command works on custom labels. Previously you'd get the error `ERROR running force:source:convert: The package root directory is empty`. (GitHub issue [#684](https://github.com/forcedotcom/cli/issues/684)) * FIX: The `force:source:convert` and `force:source:deploy` commands work with the EmailTemplate and EmailFolder metadata types. Previously you’d get an error such as `Cannot find folder: ExampleFolder`. (GitHub issue [#609](https://github.com/forcedotcom/cli/issues/609) and [#612](https://github.com/forcedotcom/cli/issues/612)) ## November 5, 2020 * We aren't releasing a Salesforce CLI patch this week. ## 7.78.1 (October 29, 2020) - (salesforcedx 50.3.1) * FIX: We fixed various issues with the `.forceignore` file and it works as expected. In particular, we updated the version dependencies of the core plug-in libraries and improved how the CLI handles trailing slashes in file entries. ([GitHub issue #690](../../../issues/690)) ## 7.77.1 (October 22, 2020) - (salesforcedx 50.2.0) * NEW: As part of [open-sourcing Salesforce CLI](https://developer.salesforce.com/blogs/2020/05/open-sourcing-salesforce-cli.html), we've broken out the source for the authorization commands, such as `force:auth:jwt:grant`, into their own [GitHub repo](https://github.com/salesforcecli/plugin-auth). These commands are now in the `auth` namespace. For example: `$ sfdx auth:jwt:grant -u me@my.org -f ./server.key -i 345234` As we broke out the commands, we took the opportunity to also refactor the code. We’re keeping the current `force:auth:*` commands based on the original code. Test out the new commands and let us know if they behave differently or unexpectedly. We plan to alias the `force:auth:*` commands to the new `auth:*` commands in the future. Update your CI/CD scripts and let us know if you run into any issues with the new commands. * CHANGE: The following org shape commands are now beta; they were pilot in v49. * `force:org:shape:create` * `force:org:shape:delete` * `force:org:shape:list` * CHANGE: A clarification to last week’s [`.forceignore` release note](#other-changes): To start using the new internal parser that follows the `.gitignore` patterns and rules, add this line to the top of your `.forceignore` file: `# .forceignore v2` If you don't add this line to your `.forceignore` file, the `force:source:*` commands continue to use the old parser. The commands warn you about invalid entries so you can start updating them at your convenience. * FIX: These release notes now include the version of the CLI npm package (`sfdx-cli`) released each week, such as 7.77.1. ([GitHub issue #683](../../../issues/683)) ## 7.76.1 (October 17, 2020) - (salesforcedx 50.1.1) Welcome to the first release of version 50 of the `salesforcedx` CLI plug-in in Winter '21. ### Installation Notes Update Salesforce CLI to v50 by running `sfdx update`. ```bash $ sfdx update ``` If you are installing Salesforce CLI for the first time, see [Install Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli.htm#sfdx_setup_install_cli) to install the CLI for your operating system, then run `sfdx update`. Run `sfdx plugins --core` to display the version of Salesforce CLI and the installed `salesforcedx` plug-in. ```bash $ sfdx plugins --core @oclif/plugin-autocomplete 0.1.5 (core) @oclif/plugin-commands 1.3.0 (core) @oclif/plugin-help 3.2.0 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.9.0 (core) @oclif/plugin-update 1.3.10 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-trust 3.4.3 (core) alias 1.1.2 (core) config 1.1.8 (core) generator 1.1.3 (core) salesforcedx 50.1.1 (core) // salesforcedx plug-in version ├─ templates 50.1.0 (core) ├─ custom-metadata 1.0.10 (core) ├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core) ├─ apex 0.1.0 (core) └─ salesforce-alm 50.1.1 (core) sfdx-cli 7.76.1 (core) // Salesforce CLI version ``` ### Uninstall the Pre-Release Version of the salesforcedx CLI Plug-In If you installed the pre-release version of the `salesforcedx` v50 plug-in, uninstall it and update the CLI. We’re no longer updating the pre-release v50 plug-in. ```bash $ sfdx plugins:uninstall salesforcedx $ sfdx update ``` ### New Commands * `force:package:version:displayancestry` Create visualizations of your package or package version's ancestry tree. View the visualization in Salesforce CLI or use the `--dotcode` parameter to generate output that you can use in graph visualization software. * `force:package:version:delete` * `force:package:delete` Deletes the package or package version. You can't recover deleted packages or package versions, or specify them as dependencies. New installations of the package will fail. You can’t delete released versions of second-generation managed packages. ### Removed Commands These commands were deprecated in v49 and removed in v50. You can continue using them by installing the [Lightning Testing Service CLI Plug-in](https://github.com/forcedotcom/plugin-lightning-test-service). Salesforce doesn't support or update this plug-in. * `force:lightning:test:install` * `force:lightning:test:run` ### New Parameters * `force:package:create --errornotificationusername (-o)` * `force:package:update --errornotificationusername (-o)` Designate an active Dev Hub org user to receive email notifications for unhandled Apex exceptions, as well as install, upgrade, or uninstall failures associated with your packages. Specify the username during package creation, or when you update the package with the `force:package:update` command. ### Other Changes * When parsing the `.forceignore` file, Salesforce CLI uses the same rules and patterns as [git uses with the `.gitignore` file](https://git-scm.com/docs/gitignore). As a result, some entries in your existing `.forceignore` files might be invalid. The `force:source:*` commands warn you about any invalid entries. * FIX: The `force:source:convert` command works correctly when you individually convert two or more custom fields of the same custom object. For example, let’s say your custom object Flower__c has two custom fields: Color__c and Size__c. Previously, this command would convert only one custom field, now it correctly converts all specified fields: ```bash $ sfdx force:source:convert -m CustomField:Flower__c.Color__c,CustomField:Flower__c.Size__c ``` This fix also applies when using the `-x` parameter to specify a manifest file that lists these fields individually. The fix also applies to `force:source:deploy`, which executes a convert before it deploys. ([GitHub issue #628](../../../issues/628)) * As [previously announced](./v49.md#49140-october-8-2020), we've reorganized the Salesforce DX Developer and Setup Guides to improve their usability and better align with how the Salesforce developer tools have evolved over time. In particular, we've moved most of the CLI Configuration and Tips topics to the [Salesforce CLI Setup Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm) and the Dev Hub topics to the [Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm). You might need to refresh your bookmarks. **TIP**: If a bookmark to one of these guides no longer works, try changing the first two `setup` parts of the URL to `dev`, or vice versa. For example, the old URL to the CLI Runtime Configuration Values topic was: `https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_cli_config_values.htm` Now it's: `https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_dev_cli_config_values.htm` ================================================ FILE: releasenotes/v49.md ================================================ # Salesforce CLI v49 Release Notes This file has moved. [Here's the new location](sfdx/v49.md). ================================================ FILE: releasenotes/v50.md ================================================ # Salesforce CLI v50 Release Notes This file has moved. [Here's the new location](sfdx/v50.md). ================================================ FILE: tsconfig.json ================================================ { "files": [], "references": [ { "path": "./.github/actions/new-issue" }, { "path": "./.github/actions/validate-issue" } ] }