RELEASE @W-18117811@ Conducting v5.0.0 release

.github/ISSUE_TEMPLATE/0-code_analyzer_bug.yml

@@ -74,7 +74,7 @@ body:
       description: |
         What do you get from the command "sf plugins"?
       placeholder: |
-        Example: code-analyzer 5.0.0-beta.0
+        Example: code-analyzer 5.0.0
     validations:
       required: true
   - type: input

.github/workflows/apply-npm-tag-to-version.yml

@@ -8,13 +8,14 @@ on:
         type: choice
         options:
           - '@salesforce/plugin-code-analyzer'
-          - '@salesforce/sfdx-scanner'
+          # TODO: Remove after April Release
+          - '@salesforce/sfdx-scanner' 
       tag_name:
         description: 'Tag Name (ex: latest):'
         required: true
         type: string
       version:
-        description: 'Version (ex: 4.8.0):'
+        description: 'Version (ex: 5.2.0):'
         required: true
         type: string
       confirm:

.github/workflows/automated-release-tasks.yml

@@ -31,17 +31,22 @@ jobs:
     needs: verify-should-run
     if: ${{ needs.verify-should-run.outputs.should-run == 'true' }}
     steps:
-      - name: Invoke v5 beta workflow
+      - name: Invoke v5 workflow
         uses: actions/github-script@v6
         with:
           github-token: ${{ secrets.SVC_CLI_BOT_GITHUB_TOKEN }}
+          # TODO: remove inputs after April Release; will default to minor
           script: |
             await github.rest.actions.createWorkflowDispatch({
               owner: context.repo.owner,
               repo: context.repo.repo,
               workflow_id: 'create-release-branch.yml',
-              ref: 'dev'
+              ref: 'dev',
+              inputs: {
+                "release-type": "patch"
+              }
             });
+# TODO: Remove this after last v4.x release in April
   create-v4-release-branch:
     runs-on: macos-latest
     needs: verify-should-run

.github/workflows/create-release-branch.yml

@@ -1,6 +1,17 @@
 name: create-release-branch
 on:
   workflow_dispatch:
+    inputs:
+      # When the workflow is executed manually, the user can select whether the branch should correspond to a major,
+      # minor, or patch release.
+      release-type:
+        type: choice
+        description: What kind of release?
+        options:
+          - major
+          - minor
+          - patch
+        required: true
 
 jobs:
   create-release-branch:
@@ -20,11 +31,19 @@ jobs:
       - uses: actions/setup-node@v4
         with:
           node-version: 'lts/*' # Always use Node LTS for building dependencies.
-      - run: yarn
+      - run: npm install
       # Increment the version as desired locally, without actually committing anything.
       - name: Locally increment version
         run: |
-          npm --no-git-tag-version version prerelease --preid beta
+          # A workflow dispatch event lets the user specify what release type they want.
+          if [[ "${{ github.event_name }}" = "workflow_dispatch" ]]; then
+            RELEASE_TYPE=${{ github.event.inputs.release-type }}
+          # The regularly scheduled releases are always minor.
+          else
+            RELEASE_TYPE=minor
+          fi
+          # Increment the version as needed.
+          npm --no-git-tag-version version $RELEASE_TYPE
       # The branch protection rule for `release-x.y.z` branches prevents pushing commits directly. To work around this,
       # we create an interim branch that we _can_ push commits to, and we'll do our version bookkeeping in that branch
       # instead.

.github/workflows/daily-smoke-tests-v4.yml

@@ -0,0 +1,29 @@
+#TODO: remove v4 with April Release
+name: daily-smoke-tests-v4
+on:
+  workflow_dispatch: # As per documentation, the colon is necessary even though no config is required.
+  schedule:
+    # Cron syntax is "minute[0-59] hour[0-23] date[1-31] month[1-12] day[0-6]". '*' is 'any value,' and multiple values
+    # can be specified with comma-separated lists. All times are UTC.
+    # So this expression means "run at 13:30 UTC every day". This time was chosen because it corresponds to
+    # 8:30AM CDT, meaning that any issues will be surfaced before the start of business.
+    - cron: "30 13 * * *"
+jobs:
+  smoke-test:
+    uses: ./.github/workflows/run-tests.yml
+    with:
+      node-matrix: "[{version: 'lts/*', artifact: 'lts'}, {version: 'latest', artifact: 'latest'}]"
+  v4-smoke-test:
+    runs-on: macos-latest
+    steps:
+      - name: Invoke v4 smoke tests
+        uses: actions/github-script@v6
+        with:
+          github-token: ${{ secrets.SVC_CLI_BOT_GITHUB_TOKEN }}
+          script: |
+            await github.rest.actions.createWorkflowDispatch({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              workflow_id: 'daily-smoke-tests.yml',
+              ref: 'dev-4'
+            });

.github/workflows/daily-smoke-tests.yml

@@ -1,6 +1,6 @@
 name: daily-smoke-tests
 on:
-  workflow_dispatch: # As per documentation, the colon is necessary even though no config is required.
+  workflow_dispatch:
   schedule:
     # Cron syntax is "minute[0-59] hour[0-23] date[1-31] month[1-12] day[0-6]". '*' is 'any value,' and multiple values
     # can be specified with comma-separated lists. All times are UTC.
@@ -9,20 +9,8 @@ on:
     - cron: "30 13 * * *"
 jobs:
   smoke-test:
+  # We run the daily smoke tests against 'dev' to validate that the code currently in development is still valid
     uses: ./.github/workflows/run-tests.yml
     with:
       node-matrix: "[{version: 'lts/*', artifact: 'lts'}, {version: 'latest', artifact: 'latest'}]"
-  v4-smoke-test:
-    runs-on: macos-latest
-    steps:
-      - name: Invoke v4 smoke tests
-        uses: actions/github-script@v6
-        with:
-          github-token: ${{ secrets.SVC_CLI_BOT_GITHUB_TOKEN }}
-          script: |
-            await github.rest.actions.createWorkflowDispatch({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              workflow_id: 'daily-smoke-tests.yml',
-              ref: 'dev-4'
-            });
+      target-branch: dev

.github/workflows/publish-to-npm.yml

@@ -53,7 +53,7 @@ jobs:
     with:
       ctc: false # We've been told we don't have to care about this until someone makes us care.
       sign: true
-      tag: latest-beta-rc # Publish as a release candidate, so we can do our validations against it.
+      tag: latest-rc # Publish as a release candidate, so we can do our validations against it.
       githubTag: ${{ github.event.release.tag_name || inputs.tag }}
     secrets: inherit
   # Step 3: Run smoke tests against the release candidate.
@@ -84,7 +84,7 @@ jobs:
           python-version: '>=3.10'
       # Install SF, and the release candidate version.
       - run: npm install -g @salesforce/cli
-      - run: sf plugins install @salesforce/plugin-code-analyzer@latest-beta-rc
+      - run: sf plugins install @salesforce/plugin-code-analyzer@latest-rc
       # Log the installed plugins for easier debugging.
       - run: sf plugins
       # Attempt to run the smoke tests.
@@ -105,7 +105,6 @@ jobs:
           node-version: 'lts/*'
       - run: |
           echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > ~/.npmrc
-          npm dist-tag add @salesforce/plugin-code-analyzer@${{ github.event.release.tag_name || inputs.tag }} latest-beta
           npm dist-tag add @salesforce/plugin-code-analyzer@${{ github.event.release.tag_name || inputs.tag }} latest
   # Step 5: Create a Pull Request for merging `main` into `dev`
   create-main2dev-pull-request:

.github/workflows/run-tests.yml

@@ -33,11 +33,11 @@ jobs:
       - uses: actions/setup-node@v4
         with:
           node-version: ${{ matrix.node.version }}
-      - run: yarn
-      - run: yarn build
-      - run: yarn test
+      - run: npm install
+      - run: npm run build
+      - run: npm run test
         id: jest-tests
-      - run: yarn lint
+      - run: npm run lint
       - name: Upload full artifact
         if: ${{ always() }}
         uses: actions/upload-artifact@v4
@@ -61,8 +61,8 @@ jobs:
         with:
           node-version: 'lts/*' # Always use Node LTS for building the tarball
       # Install/build dependencies
-      - run: yarn
-      - run: yarn build
+      - run: npm install
+      - run: npm run build
       # Create the tarball
       - run: npm pack
       # Upload the tarball as an artifact
@@ -115,7 +115,7 @@ jobs:
         shell: bash
         run: |
           # We need to determine the Tarball's name first.
-          TARBALL_NAME=$(ls ~/downloads/tarball | grep salesforce-plugin-code-analyzer-5\\.0\\.0-beta\\.[0-9]*\\.tgz)
+          TARBALL_NAME=$(ls ~/downloads/tarball | grep salesforce-plugin-code-analyzer-.*\\.tgz)
           # We need to determine the Tarball's location in an installable way.
           # Get the path to the download folder. Swap out backslashes for forward slashes to ensure Windows compatibility.
           RAW_TARBALL_PATH=`echo '${{ steps.download.outputs.download-path }}' | tr '\\' '/'`
@@ -130,4 +130,3 @@ jobs:
         with:
           name: smoke-test-results-${{ runner.os }}-node-${{ matrix.node.artifact }}
           path: smoke-test-results
-

.github/workflows/validate-pr.yml

@@ -6,6 +6,7 @@ on:
 jobs:
   # We want to prevent cross-contamination between the 4.x and 5.x pipelines. So we should prevent PRs
   # based on this flow to merge into `dev-4` or `main-4`.
+  # TODO: Remove this after the April release, since we won't care after that to maintain v4
   verify_target_branch:
     runs-on: ubuntu-latest
     steps:

.gitignore

@@ -8,7 +8,6 @@
 /.nyc_output
 /dist
 /lib
-/package-lock.json
 /tmp
 node_modules
 /out
@@ -161,4 +160,4 @@ sfge*.log.gz
 
 npm-shrinkwrap.json
 
-.npmrc
+.npmrc

messages/config-command.md

@@ -4,11 +4,11 @@ Display the current state of configuration for Code Analyzer.
 
 # command.description
 
-Code Analyzer gives you the ability to configure settings that modify Code Analyzer's behavior, to override the tags and severity levels of rules, and to configure the engine specific settings.  Use this command to see the current state of this configuration. You can also save this state to a YAML-formatted file that you can modify for your needs.
+Code Analyzer gives you the ability to configure settings that modify Code Analyzer's behavior, to override the tags and severity levels of rules, and to configure the engine specific settings. Use this command to see the current state of this configuration. You can also save this state to a YAML-formatted file that you can modify for your needs.
 
 To apply a custom configuration with Code Analyzer, either keep your custom configuration settings in a `code-analyzer.yml` file located in the current folder from which you are executing commands, or specify the location of your custom configuration file to the Code Analyzer commands with the --config-file flag.
 
-We're continually improving Salesforce Code Analyzer. Tell us what you think! Give feedback at http://sfdc.co/CodeAnalyzerFeedback.
+We're continually improving Salesforce Code Analyzer. Tell us what you think! Give feedback at https://sfdc.co/CodeAnalyzerFeedback.
 
 # command.examples
 
@@ -28,9 +28,9 @@ We're continually improving Salesforce Code Analyzer. Tell us what you think! Gi
 
   <%= config.bin %> <%= command.id %> --rule-selector Recommended
 
-- Display the configuration state associated with all the rules that are applicable to your workspace folder, `./src`:
+- Display the configuration state associated with all the rules that are applicable to the files targeted within the folder `./src`:
 
-  <%= config.bin %> <%= command.id %> --workspace ./src
+  <%= config.bin %> <%= command.id %> --target ./src
 
 - Display any relevant configuration settings associated with the rule name 'no-undef' from the 'eslint' engine:
 
@@ -42,29 +42,45 @@ We're continually improving Salesforce Code Analyzer. Tell us what you think! Gi
 
 # flags.workspace.summary
 
-Set of files you want to include in the code analysis.
+Set of files that make up your workspace.
 
 # flags.workspace.description
 
-Use the --workspace flag to display only the configuration associated with the rules that apply to the files that make up your workspace. Typically, a workspace is a single project folder that contains all your files. But it can also consist of one or more folders, one or more files, and use glob patterns (wildcards). If you specify this flag multiple times, then your workspace is the sum of the files and folders.
+Use the `--workspace` flag to display only the configuration associated with the rules that apply to the files that make up your workspace. Typically, a workspace is a single project folder that contains all your files. But it can also consist of one or more folders, one or more files, and use glob patterns (wildcards). If you specify this flag multiple times, then your workspace is the sum of the files and folders.
 
-This command uses the type of file in the workspace, such as JavaScript or Typescript, to determine the rules to include in the configuration state. For example, if your workspace contains only JavaScript files, the command doesn't include TypeScript rules. The command uses a file's extension to determine what kind of file it is, such as ".ts" for TypeScript.
+This command uses the types of files in the workspace, such as JavaScript or Typescript, to determine the applicable configuration state. For example, if your workspace contains only JavaScript files, then the command doesn't display configuration state associated with TypeScript rules. The command uses a file's extension to determine what kind of file it is, such as ".ts" for TypeScript.
 
-Some engines may be configured to add additional rules based on what it finds in your workspace.  For example, if you set the "engines.eslint.auto_discover_eslint_config" value of your `code-analyzer.yml` file to true, then supplying your workspace allows the "eslint" engine to examine your files in order to find ESLint configuration files that could potentially add in additional rules.
+Some engines can be configured to add additional rules based on what it finds in your workspace. For example, if you set the engines.eslint.auto_discover_eslint_config value of your `code-analyzer.yml` file to true, then supplying your workspace allows the "eslint" engine to examine your files in order to find ESLint configuration files that could potentially add in additional rules.
+
+If you specify `--target` but not `--workspace`, then the current folder '.' is used as your workspace.
+
+# flags.target.summary
+
+Subset of files within your workspace that you want to target for analysis.
+
+# flags.target.description
+
+Use the `--target` flag to display the configuration state associated with the rules that apply to only a subset of targeted files within your workspace. You can specify a target as a file, a folder, or a glob pattern. If you specify this flag multiple times, then the full list of targeted files is the sum of the files and folders.
+
+The command uses the type of the targeted files, such as JavaScript or Typescript, to determine which configuration state is applicable. For example, if you target only JavaScript files, then the command doesn't display the configuration state associated with TypeScript rules. The command uses a file's extension to determine what kind of file it is, such as ".ts" for TypeScript.
+
+Each targeted file must live within the workspace specified by the `–-workspace` flag.
+
+If you specify `--workspace` but not `--target`, then all the files within your workspace are targeted.
 
 # flags.rule-selector.summary
 
 Selection of rules, based on engine name, severity level, rule name, tag, or a combination of criteria separated by colons.
 
 # flags.rule-selector.description
 
-Use the --rule-selector flag to display only the configuration associated with the rules based on specific criteria. You can select by engine, such as the rules associated with the "retire-js" or "eslint" engine. Or select by the severity of the rules, such as high or moderate. You can also select rules using tag values or rule names.
+Use the `--rule-selector` flag to display only the configuration associated with the rules based on specific criteria. You can select by engine, such as the rules associated with the "retire-js" or "eslint" engine. Or select by the severity of the rules, such as high or moderate. You can also select rules using tag values or rule names.
 
-You can combine different criteria using colons to further filter the list; the colon works as an intersection.  For example, "--rule-selector eslint:Security" reduces the output to only contain the configuration state associated with the rules from the "eslint" engine that have the "Security" tag. To add multiple rule selectors together (a union), specify the --rule-selector flag multiple times, such as "--rule-selector eslint:Recommended --rule-selector retire-js:3".
+You can combine different criteria using colons to further filter the list; the colon works as an intersection. For example, `--rule-selector eslint:Security` reduces the output to only contain the configuration state associated with the rules from the "eslint" engine that have the "Security" tag. To add multiple rule selectors together (a union), specify the `--rule-selector` flag multiple times, such as `--rule-selector eslint:Recommended --rule-selector retire-js:3`.
 
 If you don't specify this flag, then the command uses the "all" rule selector.
 
-Run `<%= config.bin %> <%= command.id %>  --rule-selector Recommended` to display the configuration state associated with just the 'Recommended' rules, instead of all the rules.
+Run `<%= config.bin %> <%= command.id %> --rule-selector Recommended` to display the configuration state associated with just the 'Recommended' rules, instead of all the rules.
 
 # flags.config-file.summary
 
@@ -82,4 +98,6 @@ Output file to write the configuration state to. The file is written in YAML for
 
 # flags.output-file.description
 
-Use this flag to write the final config to a file, in addition to the terminal.
+If you specify a file within folder, such as `--output-file ./config/code-analyzer.yml`, the folder must already exist, or you get an error. If the file already exists, a prompt asks if you want to overwrite it.
+
+If you don't specify this flag, the command outputs the configuration state to the terminal.