Minimize use of the Salesforce CLI for deployment

Issue #1717 resolved
Scott Wells repo owner created an issue

It seems that there's more overhead to the Salesforce CLI when deploying than originally thought, in particular on Windows host machines. As a result, I'd like to use direct APIs as much as possible even in source format projects against non-source tracked orgs.

The first step will be to do as much as possible short of performing an actual source-to-metadata format conversion myself. That means that if you've selected things that can be sent via the Tooling API, IC will already do the right thing. If not and what you've selected has the same on-disk representation in both source format and metadata format, IC should be able to use the Metadata API to deploy it all. And if that's not possible, IC will just use the force:source:deploy to take care of it.

Taking this to the logical extreme, though, IC could send everything via the API if it converted source format to metadata format as it builds its deployment archive. That's a much more involved piece of work, though, and the first phase already addresses the primary use case of interactive development just by virtue of the metadata types that it already handles (Apex, VF, Aura, and LWC). I'll start there.

Comments (3)

  1. Scott Wells reporter

    Here's a build that implements the first step. I'd like to get some users to try it out and report improvements, if any, before releasing it broadly.

    It can be installed by downloading the attached archive--don't extract it--and using Settings/Preferences>Plugins>Install plugin from disk (under the gear drop-down menu). I'd love to hear whether it makes a difference in particular with LWC development where the development is making lots of little changes and deploying them frequently.

  2. Scott Wells reporter

    The first step was delivered with 2.1.4.1. I'm going to resolve this as I think that addresses the primary motivation for this change, namely the ongoing/interactive development use case against supported metadata types that were subject to this issue.

  3. Log in to comment