Announcing the Source Plugin beta!

[shetzel]

Want faster and more reliable deploys and retrieves? Try using the new Source Plugin beta. Just install the plugin in your Salesforce CLI and run the same commands as you normally would.

Steps:

1. run sfdx update to update the CLI and plugins (if you installed via npm, you should also run npm install -g sfdx-cli)
2. sfdx plugins:install @salesforce/plugin-source
3. sfdx which force:source:deploy - ensure it reports that the command is coming from the plugin: @salesforce/plugin-source
4. Run any of the commands listed below
5. sfdx plugins:uninstall @salesforce/plugin-source when you’re done testing to go back to the normal version

List of Commands:

• force:source:deploy
• force:source:retrieve
• force:source:convert
• force:source:deploy:report
• force:source:deploy:cancel

Fixed Bugs:

• sfdx force:source:deploy --manifest ERROR: Cannot read property 'getMetadataName' of undefined. (sfdx force:source:deploy --manifest ERROR: Cannot read property 'getMetadataName' of undefined. #16) @JimBTek
• Deploying using force:source:deploy -m Report deploys all files with report in the name or filepath (Deploying using force:source:deploy -m Report deploys all files with report in the name or filepath #184) @shliachtx
• force:source:retrieve -x ... doesn't update static resources (force:source:retrieve -x ... doesn't update static resources #190) @ChuckJonas
• Validation and progress bar (Validation and progress bar #347) @maaaaarco
• sfdx force:source:deploy and sfdx force:mdapi:deploy return 0 when deployment is timed out (sfdx force:source:deploy and sfdx force:mdapi:deploy return 0 when deployment is timed out #461) @MuriloKakazu
• Object Translation failing to be deployed (Object Translation failing to be deployed #477) @ilanbalink
• sfdx force:source:retrieve is adding fields with the same name as the object at the top level of the object folder. (sfdx force:source:retrieve is adding fields with the same name as the object at the top level of the object folder. #638) @ameliaclarke
• force:source:retrieve -n "PackageName" doesn't retrieve Custom Object sub components. (force:source:retrieve -n "PackageName" doesn't retrieve Custom Object sub components.  #644) @jjulicher
• sfdx force:source:convert for Custom Label in package.xml is not working (sfdx force:source:convert for Custom Label in package.xml is not working #673) @saicharanreddyk
• .js-meta.xml file name gets changed to .css-meta.xml (.js-meta.xml file name gets changed to .css-meta.xml #761) @Paul-Browne

Known Issues:

1. Due to changes in the design and performance of the core code used by the plugin (SDR library), hooks are not backwards compatible. For example, the postretrieve hook essentially replaces the postsourceupdate hook for retrieves, and the payloads are different.
2. Retrieving via packagenames parameter puts the package source in the default project directory, rather than in a separate directory.
3. Deploying multiple packages via manifest (package.xml) doesn’t resolve certain metadata (e.g., CustomObjects) correctly when that metadata is split across packages.

Reporting Bugs:

Open any other bugs you find using github issues: https://github.com/forcedotcom/cli/issues. We are not accepting support cases through normal Salesforce support channels during the beta.

Source Code:

Plugin code is at https://github.com/salesforcecli/plugin-source if you want to see how things are working or contribute a fix.
SDR code is at https://github.com/forcedotcom/source-deploy-retrieve if you’re curious about the internals.

[NTaylor1993]

Hi @shetzel any chance you could go into any detail on scenarios where this plugin leads to faster deploys? I have installed it to try out and see if there is any performance deviation but so far with all of the deploys I have tested the times are within standard deviation of the logs I have available on times.

For reference the deploy process I am using is just to create a new org and then use sfdx force:source:deploy -p ./ to deploy everything as an initial deploy. This ends up taking 30-100 minutes normally to complete depending on which instance my scratch org is created on.

Just wondering if there are any changes that we can make to our process to get faster deploys with this plugin.

[shetzel]

@NTaylor1993 - Thanks for trying the new plugin! In short, the answer to your question is "all scenarios", with the caveat that we're talking about client side performance (CLI and plugins), not server. So if your total deploy time without the new plugin was 45 mins, with 5 mins on the client and 40 mins on the server, and the new plugin is 42 mins, with 2 mins on the client and 40 mins on the server it will not seem like much. It will probably be much more noticeable with smaller deploys/retrieves where the server time doesn't account for such a large percentage.
The client side performance gain is from switching to a new library (the @salesforce/source-deploy-retrieve lib) which does much less file system reading/writing and instead uses streams.

[NTaylor1993]

@shetzel thanks for getting back to me, as I mention did not see any changes outside of expected standard deviation for the instances deploying on but that is normally quite a large deviation so explains that. It is definitely a very large source so long server side deploy times.

[steals]

running sfdx force:source:deploy -x manifest/package.xml on the latest cli version throws ERROR running force:source:deploy: core_1.Logger.childFromRoot is not a function