"Salesforce CLI executable" installed via nvm / node follows symlink

Issue #2466 resolved
Mark Mindenhall created an issue

I need to switch between node versions (14.x and 18.x at the moment) to do work in various non-Salesforce projects at work, and I use nvm to manage them. My “default” nvm version is v18.16.0.

I have installed the Salesforce executable globally in that version of node:

npm install @salesforce/cli --global

This puts the sf executable into my path as follows, and the sf file itself is a symbolic link:

$ which sf
/Users/markmindenhall/.nvm/versions/node/v18.16.0/bin/sf

$ ls -l /Users/markmindenhall/.nvm/versions/node/v18.16.0/bin/sf
lrwxr-xr-x  1 markmindenhall  staff  46 Nov 16 15:22 /Users/markmindenhall/.nvm/versions/node/v18.16.0/bin/sf@ -> ../lib/node_modules/@salesforce/cli/bin/run.js

In the IC2 Salesforce DX settings (Languages & Frameworks → Illuminated Cloud → Salesforce DX), the “Salesforce CLI executable” is a file picker widget. When I use the file picker widget to navigate to the sf executable, the file picker follows the symlink, and I get the target as the CLI executable instead of the sf symlink:

When I select this file, I get repeated error notifications that go on about once per second without stopping:

The constant stream of error notifications seems to block the ability to reopen the settings dialog, or to do basically anything else in the IDE other than watch the notifications continue. This requires a Force Quit to make it stop.

Until just a few days ago, I had the SF CLI installed via the downloaded .pkg file. I uninstalled that and installed directly with the npm command above in order to test the DX@Scale scratch org pooling tools, which install as a separate npm dependency (npm install --global @dxatscale/sfpowerscripts) that makes calls down to the sf CLI. Therefore, I wanted both tools installed in the same instance of node.

The expected behavior here would be either:

  • the file picker doesn’t follow the symlink and the sf command is usable by IC2
  • the file picker continues to follow the symlink, but the error condition is avoided and the symlink target is usable by IC2

Thanks!

Comments (18)

  1. Scott Wells repo owner

    Hi, Mark. Unfortunately I’m not seeing this behavior. I test explicitly with an NPM-based CLI distribution on one of my machines to suss out issues/differences, and I just tested this on that machine. I can confirm that the path shown on this machine for which sf – in this case /usr/bin/sf – is a symlink to ../lib/node_modules/@salesforce/cli/bin/run.js. In the IC2 Salesforce DX settings, I unchecked Use Salesforce CLI executable from the execution path and explicitly selected /usr/bin/sf as the value for Salesforce CLI executable via the file chooser and it selected /usr/bin/sf.

    Now, to be clear, what I described above is on Linux and not Mac OS which I suspect you’re using. I also checked what would happen if I selected a symlink on Mac OS and I do see it resolving to the link target instead of the link itself. Unfortunately that’s a behavior of the native file chooser on Mac OS that the JetBrains IDE uses instead of its Swing-based file chooser that is used on Linux and Windows. I’m not sure why that difference exists, but that seems to be the root cause of the issue.

    Since you’re trying to use the one displayed by which sf, any reason that you don’t just click the Reset button and enable Use Salesforce CLI executable from the execution path? That would ensure that the desired path is used. I’m assuming it’s because the one you add to the execution path changes and might not be the one you want at any given time?

  2. Mark Mindenhall reporter

    Hi Scott! A few comments:

    1. Yes, I’m on a Mac.
    2. I don’t see a Use Salesforce CLI executable from the execution path checkbox anywhere in the settings.
    3. Hitting the Reset button in the Salesforce DX settings tab didn’t change the value of the Executable.
    4. The reason I have to set the CLI executable explicitly is because starting Intellij from the Dock is not loading my shell environment, which would be needed to execute the version found in the execution path.
    5. Since you have an executable at /usr/bin/sf, I’m guessing that you installed node via a package manager? That wouldn’t work for me because I need to switch between node major versions for different projects.

    My current workaround here is that I have the Salesforce CLI installed both via npm in node18, and also via the downloadable installer, which gives me an executable at /usr/local/lib/sf/bin/sf. This works, but requires updating both of them to keep them at the same version.

    Go ahead and close this.

  3. Scott Wells repo owner

    Mark, can you confirm the IC2 build you have installed? The issue with environment variable sourcing/propagation to the Salesforce CLI should have been resolved in 2.2.7.7, and the fact that you’re not seeing the Use Salesforce CLI executable from execution path checkbox sounds suspicious as well. That should show if/when you reset the Salesforce CLI executable value. If you’re definitely seeing this on the most recent build, something isn’t quite right.

  4. Scott Wells repo owner

    Thanks. So if you click the Reset button to the right of the executable path text field, it doesn’t show that checkbox? If so, that’s very, very strange. Also, be aware that while IC2 theoretically can work with sf, it’s only tested with sfdx. Do you see a different behavior when you choose sfdx? Wondering if I have something kind of hard-coded somewhere for sfdx vs. sf.

  5. Piotr Kożuchowski

    Hey,

    Just wanted to report that after installing SF CLI from node, Webstorm is now stuck in never ending loop of loading CLI and it’s difficult to change the path back.

    I’ve had standard executable, then installed through npm to get new version and this happened.

  6. Scott Wells repo owner

    Piotr, what is the file at path C:\Users\piotr\AppData\Local\sfdx\client\7.209.6-8ba3197\bin\sfdx.cmd? I’m assuming based on what I’m seeing there that it’s not an executable script, correct? Was that explicitly selected or picked up from the %PATH% environment variable? I’m assuming the former given the bin\..\7.209.6.8ba3197 portion of the path that wouldn’t have come from the system’s execution path, but perhaps that’s an incorrect assumption?

    As a workaround, you can close the IDE and open %APPDATA%\JetBrains\WebStorm2023.3\options\illuminatedCloud.xml in your favorite editor, then look for the option sfdxExecutablePath and either remove or modify it. If it has the \bin\..\ path segment, it could be that just removing that portion so that it’s effectively the straight path to sfdx.cmd will resolve it. If that’s the case, I think it should just be a matter of IC2 ensuring that the selected script’s path is always the file’s absolute path and doesn’t include any relative path components.

  7. Piotr Kożuchowski

    Hi Scott,

    I was able to fix the issue - webstorm slowed down a lot due to constant notifications, but eventually I got to the IC2 app settings, then changed the path to C:/Users/piotr/AppData/Roaming/npm/sfdx.cmd and it worked - this is the correct path for npm installation.

    Now, regarding the previous path (sfdx\client\7.209.6-8ba3197\bin\sfdx.cmd) - there was a checkbox “Use Salesforce CLI executable from execution path” - I think the issue started when I’ve checked this, so somehow this path was resolved after checking the checkbox. I didn’t set it explicitly to sfdx\client\7.209.6-8ba3197\bin\sfdx.cmd%app

  8. Scott Wells repo owner

    Thanks for the update, Piotr. Yes, I tried to use a path with a relative path component – but to a valid sfdx script – and it worked without issues. So what exactly is the file at path C:\Users\piotr\AppData\Local\sfdx\client\7.209.6-8ba3197\bin\sfdx.cmd? It seems that’s the root cause of the issue. Is that not a valid executable file? Is it perhaps a link or something else?

  9. Eric Alexander

    Having same issue. Updating IC worked but now all commands are not recognized since I do not have SFDX installed. I had to reinstall SFDX on top of SF to get IC to work again. When I tried with just SF is kept giving me errors that force [commands] were not valid sf commands

  10. Scott Wells repo owner

    Eric, I’m not sure I understand “When I tried with just SF” since the v2 CLI installer includes everything needed for 100% backward compatibility with the sfdx commands. Did you have a very old install of the CLI that was replaced perhaps?

  11. Eric Alexander

    After updating the nm sf cli I was unable to use IJ and IC as it said there was no DX Executable found. Indeed under the settings if IC it was blank. Trying to set it to the current path provided by which sfdx I got several error ever second.

    I update IC to the latest version and it seemed to find the executable again. But anything I did caused a force org list is not a valid sf command.

    So I had to install SFDX via the package installer to get it working again.

  12. Scott Wells repo owner

    Hmmmmm…I use an npm-based install on my Ubuntu Linux test machine. On that machine, which sfdx returns /usr/bin/sfdx, and that’s what IC2 automatically finds via the execution search path in Illuminated Cloud | Configure Application | Salesforce DX. Everything works fine on that machine. Can you explain how your environment might have been different since I’m not seeing the same behavior?

  13. Scott Wells repo owner

    Okay, so to be clear, which sfdx displays /Users/ericalexander/.nvm/versions/node/v18.14.2/bin/sfdx, correct? And is that a physical file or a symbolic link? And if it’s a symbolic link, what is the actual target file, and does IC2 automatically pick up the link or the link target as its executable script?

  14. Eric Alexander

    After installing sfdx I have it set to: /usr/local/lib/sfdx/bin/sfdx.

    I redid the sf as the executable like and it is now working so after closing everything and trying again I am no longer clear on the issue as it stands. I will open a new ticket if it breaks again

  15. Scott Wells repo owner

    Resolving due to lack of activity, but my guess is that there is still some variant of this issue that still exists. If you're affected, please reopen with explicit instructions for how to reproduce so that I can do so and put this one to rest.

  16. Log in to comment