Handover execution from global CLI to local CLI when using NPM

[felipeplets]

The Salesforce CLI can be installed via the NPM registry, either globally or locally (in a project).

To install it globally you can run:

npm install @salesforce/cli --global

To install it locally in a given project you can use:

npm install @salesforce/cli

The advantages of installing it by project are

• We can run package.json scripts using this version of the CLI without having it installed globally
• We can have multiple projects using different versions and both will work correctly when running given scripts.. i.e.:
  • Project A uses SF CLI 2.0.1
  • Project B uses SF CLI 2.43.7
• we can enforce centrally (as part of the project/repository) the version of the CLI that users should be using

The disadvantage of only installing it locally is that you can't run SF CLI commands directly in your terminal like sf --version you would need to run it via NPM with a command like npx sf --version.

You could install it globally and locally, so you could have something like:

• Globally installed version SF CLI 2.10.2
• Project A uses SF CLI 2.0.1
• Project B uses SF CLI 2.43.7

In this scenario above the problem is that depending how we are running the CLI the version will be different. For instance a user running a command directly in their terminal will be using version 2.10.2, while a user running an NPM script in project A will use version 2.0.1.

A project I use regularly called NX solves this problem with the following approach, documented in their installation page:

The advantage of a global installation is that you don't have to prefix your commands with npx, yarn or pnpm. The global Nx installation hands off the process execution to the local Nx installation in your repository, which eliminates any issues with outdated globally installed packages.
Source: Installing NX Globally

Such feature would be really welcome for teams managing multiple projects or trying to enforce an SF CLI version centrally.

[VivekMChawla]

@felipeplets - Thank you for sharing this idea.

You've done an excellent job outlining the technical requirements for this idea. Unfortunately, I don't understand the functional benefits of having different CLI versions in each SFDX project.

Could you elaborate on your use cases? Specifically, could you highlight the business value associated with the advantages you shared?

Thanks!

[felipeplets]

Hi @VivekMChawla thank you for the prompt response.

I am not a long-time user of SF CLI, so I may not have enough information to back a business case here, but I can refer to the business value for my company.

The business value is:

Reduce developer experience friction due to incompatibility between the installed and the required version of given tools.

A little more context:

We have with many CLIs and runtimes needed to back the development in our repository, examples are: Python, NodeJS, PNPM, NX, Mongo Shell, and SF CLI.

These may have incompatibility between versions, for instance, PNPM 9 has breaking changes compared to PNPM 8, NX 18 has breaking changes compared to NX 17, so guaranteeing that the developers are using the right version is important.

There are many solutions to these problems, like central managing these via IT, or via other Package Managers.

We want as much as possible make this centralized as part of the repository experience and make the centralized update an easy experience. So when SF CLI 2.45.0 is released it is a matter of a single PR that updates this and all developers in their next pull will get this new version.

In this case all the developer would do is:

git pull
npm install

After running these two commands their sf --version would return the version 2.45.0, without them having to update the SF Cli and avoiding incompatibility issues.

The other side of the scenario above is that let's say we release SF CLI 3.0.0, even though that may have to break compatibilities, a developer can still install V3 globally in their machine and use in other projects. Once they come to the aforementioned repository it would delegate to the version installed in the repository and thus use the correct version.