README.md generated with oclif readme contains my sf config values as defaults

[alan-morey]

Summary

Given I have a configuration set for target-org, e.g. sf config set target-org=user@example.com.myorg, when I use yarn oclif readme to generate the README.md content for my CLI plugin, the README.md contains my configured target-org "user@example.com.myorg" as the default value for the target-org flag of my command but I do not want my personal configurations to be used as default values in README.md.

Steps To Reproduce

1. Set target-org config value

sf config set target-org=user@example.com.myorg

2. Generate a new CLI plugin

sf dev plugins generate

3. Edit src/commands/hello/world.ts and add a new flag:

'target-org': Flags.requiredOrg()

4. Build and generate README

yarn build
yarn oclif readme

5. Open README.md and view text for flag -o, --target-org

Expected result

Expected that generated flag description would look some like the following:

-o, --target-org=<value>  (required) Username or alias of the target org. Not required
                          if the `target-org` configuration variable is already set.

I was expecting the README would be generated in a generic way, not referencing my configuration values and using those to populate the defaults for flags.

Actual result

README generated by oclif readme contains flag defaults resolved from my sf config values.

-o, --target-org=<value>  (required) [default: user@example.com.myorg] Username or 
                          alias of the target org. Not required if the `target-org`
                          configuration variable is already set.

Additional information

To workaround this I have been clearing my target-org configurations, both local and global, generating the README, then re-setup my config values.

This is annoying and cumbersome.

Another alternative, is to set SF_TARGET_ORG to some value while running oclif readme

SF_TARGET_ORG=" " yarn oclif readme

This workaround is more convenient as I don't have to remember to set up my config options again.

System Information

{
  "architecture": "linux-x64",
  "cliVersion": "@salesforce/cli/2.59.6",
  "nodeVersion": "node-v18.20.3",
  "osVersion": "Linux 6.8.0-45-generic",
  "rootPath": "/home/alan.morey/.volta/tools/image/packages/@salesforce/cli/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.3 (core)",
    "@oclif/plugin-commands 4.0.14 (core)",
    "@oclif/plugin-help 6.2.11 (core)",
    "@oclif/plugin-not-found 3.2.20 (core)",
    "@oclif/plugin-plugins 5.4.7 (core)",
    "@oclif/plugin-search 1.2.8 (core)",
    "@oclif/plugin-update 4.5.6 (core)",
    "@oclif/plugin-version 2.2.12 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.15 (core)",
    "@oclif/plugin-which 3.2.13 (core)",
    "@salesforce/cli 2.59.6 (core)",
    "apex 3.4.9 (core)",
    "api 1.2.1 (core)",
    "auth 3.6.56 (core)",
    "data 3.6.5 (core)",
    "deploy-retrieve 3.12.7 (core)",
    "dev 2.4.2 (user) published 35 days ago (Mon Aug 26 2024)",
    "info 3.4.6 (core)",
    "limits 3.3.30 (core)",
    "marketplace 1.2.25 (core)",
    "org 4.5.8 (core)",
    "packaging 2.8.4 (core)",
    "schema 3.3.29 (core)",
    "settings 2.3.19 (core)",
    "sobject 1.4.35 (core)",
    "source 3.5.19 (core)",
    "telemetry 3.6.12 (core)",
    "templates 56.3.18 (core)",
    "trust 3.7.27 (core)",
    "user 3.5.29 (core)",
    "cli-plugin 1.0.0 (link) /home/alan.morey/repos/salesforce/cli-plugin"
  ]
}

[github-actions]

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.

[WillieRuemmele]

Hey @alan-morey - this is interesting. I'm thinking that this is the same code that's used to build --help output, where the default username would be useful to know during an active CLI session. But also because you're running yarn oclif readme in a directory where you have a local target-org config set which requires the directory to be a valid salesforce project.

Are you setting that config globally?

I'm sure that use case didn't cross our minds while building this, but I'm also not sure that it's a bug. Setting the SF_TARGET_ORG env var before running the script is a great workaround like you mentioned, and could be hardcoded in your package.json

[alan-morey]

@WillieRuemmele Yes, I have a global config option set for my target-org and I use local level option too.

sf config set --global target-org=mydefaultorg

My saleforce project has a sub folder cli-plugin, so that's why my local sf config options get resolved when I'm working within my cli-plugin but even when I clear the local config option, the global option will be used. So I would need to clear that too.

The resolved usernames for defaults in help totally makes sense during active CLI sessions and I think this is a great feature.

Setting SF_TARGET_ORG works fine for now as workaround, I'll probably add this to package.json anyway but that's just one resolved default value. I can see this being an issue if I have to provide overrides for many different values.

Is there any option or Environment variable to tell sf not to read my config files? Or can I configure it to read a different config path, for example SF_CONFIG_PATH=/dev/null?

Also, if SF_TARGET_ORG overrides config options set with sf config set, should generated help take that into consideration when resolving the default value for related flag? Currently it appears that setting SF_TARGET_ORG to any value means the username resolution does nothing in the help but when it's undefined the username is resolved from config option.

[WillieRuemmele]

@alan-morey - are you using Flags.requiredOrg() from @salesforce/sf-plugins-core? those flags have noCacheDefault: false so that this information shouldn't be displayed. If you are, can you verify you're on v11 of sf-plugins-core where that default has been set

[git2gus]

This issue has been linked to a new work item: W-16883857

[alan-morey]

@WillieRuemmele The generated plugin had sf-plugins-core at v10. I upgraded to latest (v11.3.10) and same issue

[WillieRuemmele]

We'll get this fixed soon

[jshackell-sfdc]

This issue has been fixed in CLI version 2.62.6 (October 16, 2024).