Inconsistency of `schema generate field` command with core platform

[k-capehart]

Summary

There is inconsistency when creating new fields in Salesforce via the CLI and via the UI.

In the UI, the default API name autopopulates after entering the label. Spaces are replaced with underscores. (i.e. Test_Field__c)

In the CLI, spaces are removed in the default value. (i.e. TestField__c)

When I run this command, I want to be consistent with my naming conventions without having to manually write the API name each time.

Steps To Reproduce

1. run sf schema generate field -l "Test Field" -o force-app/main/default/objects/Acount/
2. notice that the spaces are removed by default
3. in the UI, create a new field via Object Manager
4. notice that the spaces are replaced by underscores by default

Expected result

The default API name for a new field created via schema generate field should be consistent (replace spaces with underscores).

Actual result

The default behavior removes spaces.

Additional information

PR created: salesforcecli/plugin-sobject#752

However, I am open to discussion on this. I almost prefer no spaces, but I like consistency better.

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.62.6",
  "nodeVersion": "node-v20.18.0",
  "osVersion": "Darwin 23.6.0",
  "rootPath": "/Users/kylecapehart/.nvm/versions/node/v20.18.0/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.5 (core)",
    "@oclif/plugin-commands 4.1.3 (core)",
    "@oclif/plugin-help 6.2.14 (core)",
    "@oclif/plugin-not-found 3.2.22 (core)",
    "@oclif/plugin-plugins 5.4.14 (core)",
    "@oclif/plugin-search 1.2.11 (core)",
    "@oclif/plugin-update 4.6.3 (core)",
    "@oclif/plugin-version 2.2.14 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.18 (core)",
    "@oclif/plugin-which 3.2.15 (core)",
    "@salesforce/cli 2.62.6 (core)",
    "apex 3.5.1 (core)",
    "api 1.3.1 (core)",
    "auth 3.6.65 (core)",
    "custom-metadata 3.3.33 (user) published 25 days ago (Sat Sep 21 2024) (latest is 3.3.35)",
    "data 3.7.0 (core)",
    "deploy-retrieve 3.12.17 (core)",
    "info 3.4.9 (core)",
    "limits 3.3.32 (core)",
    "marketplace 1.2.26 (core)",
    "org 4.6.0 (core)",
    "packaging 2.8.11 (core)",
    "schema 3.3.34 (core)",
    "settings 2.3.23 (core)",
    "sobject 1.4.42 (link) /Users/kylecapehart/Documents/repos/personal/plugin-sobject",
    "source 3.5.21 (core)",
    "telemetry 3.6.15 (core)",
    "templates 56.3.22 (core)",
    "trust 3.7.33 (core)",
    "user 3.5.32 (core)",
    "kc-sf-plugin 1.4.11 (user) published 12 days ago (Fri Oct 04 2024)",
    "lightning-flow-scanner 2.34.0 (user) published 53 days ago (Sat Aug 24 2024)"
  ]
}

[github-actions]

Hello @k-capehart 👋 None of the versions of sf you shared match the latest release.

Shared: 2.61.8
Latest: 2.62.6

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue.
You can also try the rc and nightly releases! (docs)

After updating, share the full output of sf version --verbose --json

[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.

[iowillhoit]

Thanks for the PR @k-capehart! I'll run this by the team and get back to you

[VivekMChawla]

@k-capehart - Thanks for engaging with us and sharing your perspective.

I see your point about consistency. I also agree that "no spaces" should be the standard in the UX.

Unfortunately, the monthly usage of schema generate commands is too low to prioritize changing the CLI.

I'm going to close this for now, but will revisit it if usage increases. Thanks!

[k-capehart]

@VivekMChawla Thanks for the response. Does the fact that I've already submitted a PR change your perspective on priority? It would just need approval, and it's small.

Either way, I appreciate it!

[VivekMChawla]

@k-capehart - The problem isn't just the engineering work. We'd want to confirm with the broader community that we're not breaking anyone by this change in behavior, then be on the lookout for complaints if we do.

Even though the number of users is small, the due diligence on our part is enough that I can't justify the change given other priorities. I'm sorry.

[k-capehart]

No worries, thanks for the added context!