Option for a module to use locally configured default org (as defined in .sf/config.json's target-org)

[Jonny Power (he/him)]

With a project that houses many modules, we commonly rely on the sf cli's default org in tooling / scripts (e.g. org setup)

When creating an org, we often set as default within the context of the working directory with the --set-default cli option, and then have to modify the configuration in IC2 for the module afterwards.

Would be a great QoL upgrade if we could specify a special connection "DEFAULT" that would redirect to the cli's default configured target org for the current working directory (maybe most reliably obtained via sf config get target-org) - current process is to wait for scripts to complete, open the config.json file to see username, and manually update IC2's module config using the switcher in the IDE.

[Scott Wells]

Hi, Jonny. I apologize but I'm not sure that I follow the request. IC2 already has an option to set the project's CLI default org to the one selected in IC2 for the project, but it sounds like you're asking for an option to use some other org as the default perhaps? Can you please elaborate a bit more on the request? Again, sorry if I'm not following properly.

[Jonny Power (he/him)]

hmm maybe I'm not seeing that option - are you referring to this one? (screenshot attached)

My understanding of that setting is that when you set a project connection in IC2 it will also set as the default in sf cli - I'm talking about the other direction, where IC2 uses whatever is configured as default in the cli - but I could totally be missing something very obvious

[Scott Wells]

Ah, I see. So basically when you create a new IC2 project against an existing SFDX project directory, instead of prompting you for a connection, have IC2 (optionally) use the project’s existing default username/alias if present. Is that a correct understanding of the enhancement request?

[Jonny Power (he/him)]

that's right, but not just on creation of an IC2 project, but during development and lifecycle of the project as well. (e.g. new org created from tooling, set as default in cli, IC2 automatically detects and swaps as well)

[Scott Wells]

Got it. I’ll chew on it a bit. It’s obviously a very specific request and not likely applicable to many users of IC2. Having said that, it also probably wouldn’t be hard to implement at all, so I’ll see if it might fit with other (semi-)related work I’m doing in the next few weeks/months.

[Jonny Power (he/him)]

thanks Scott! makes sense - appreciate the consideration!

[Scott Wells]

Closely related to #2538 if not actually a duplicate.

[Scott Wells]

Issue #2538 was marked as a duplicate of this issue.

[Wim Tibackx]

For what it’s worth, another possible use case is having branch-based development with scratch orgs. Consider the following:

• I start work on a new feature, so I create a new feature branch and I spin up a scratch org for development of that feature.
• I can set that scratch org as my default SF scratch org locally within my directory and then use any SF-tooling without having to specify the org username/alias.
• However, for the parts in IntelliJ/IC2 I currently have to assign an alias and specifically set the IC connection to that alias. This means it then gets reflected in files that usually get checked in to VCS.
• I can either set an alias specific to my feature (“feature-123-scratch”) and make sure to not commit the changes to IntelliJ/IC2 project configuration files. This includes test run configuration files, so it’s not really an option to initially commit these files and ignore them later on.
• Or I can set a generic alias that will always be correct across all branches and can in fact live in the configuration files on my base branch (for example “development-scratch”). This does mean that I can’t easily run multiple clones of the project to work on multiple things (for example: be developing a feature in “clone-a”, taking up a quick hotfix in “clone-b”, and doing PR review in “clone-c”) because the aliases in sf cli are global to sf cli install. So once I have assigned alias “development-scratch” to one particular scratch, all my clones of the project point to that same scratch if they point to “development-scratch”.
• I’m currently on this second workflow as that’s slightly more practical. With every switch between those various clones I just have to remember to switch the alias - though that’s not a 100% success rate of course :D. The occurrences that I’m really concurrently working on multiple things is limited to “this deployment to a scratch org is taking a long time, let me check up on this other thing in the mean time”.

This could be easier if we could instead do the following:

• Set the SF CLI default scratch org locally to each clone directory and then point IC2 to $$SF_CLI_DEFAULT_SCRATCH_ORG$$.
• This means the settings files could always point to $$SF_CLI_DEFAULT_SCRATCH_ORG$$ and running different default scratch orgs side by side in different directories would work without config file changes.
• It would probably mean that IC2 has to periodically check the value for the default scratch org. I’m not sure how costly this would be.

Does this use case make sense? I’m very much open to hearing alternative solutions or any concerns,