Package.xml Utilities

[ntotten]

This isssue is the continuation of #862

This proposal introduces the concept of a Working Set (Name TBD). A Working Set is a group of metadata types or items that can be deployed or retrieved together. A working set can be exported to a package.xml file. A working set is only a concept in VS Code - it is not something that is implemented on the actual Metadata API.

Working Sets are purely temporary groups of metadata that are used to perform various tasks in VS Code - while they will persist across sessions of VS Code (mostly to avoid losing work if you accidentally close VS Code) they cannot be checked into source, nor are they designed to do production or scriptable deployments like changesets or package deployments are. The most basic case for using working sets is when developer using VS Code wants to work on a few different files at the same time and quickly deploy them to their development org to see the changes. Fundamentally, working sets are primarily just UI to expose the CLI command sfdx force:source:deploy --metadata <metata types/instance> and sfdx force:source:retrieve --metadata <metadata types/instances>. Working sets are also the way you can build apackage.xml file in VS Code. You can add items to the in-memory working set and then export them to a package.xml manifest file. In the future, this UI could be used to edit/import existing package.xml files or we could even imagine this UI being extended to help build changesets, but those features are not in the scope of this proposal now.

The pane below the metadata tree shows the items that are currently in the working set. These items can be removed by right-clicking and selecting "Remove from Working Set".

The working set pane contains three buttons:

• Save/Export - This button exports the current working set to a package.xml file. The user will be prompted for a name and location to save this file.
• Deploy Working Set - Deploys all the items in this working set to the currently selected org.
• Retrieve Working Set - Retrieves all the items in this working set from the currently selected org.

In addition to the menus, there would also be two commands in the VS Code command palette.

• SFDX: Deploy Current Working Set to Org - Deploys the items in the current working set to the org.
• SFDX: Retrieve Current Working Set from Org - Retrieves the items in the current working set from the org.

Lastly, files in the regular explorer tab could be added to the working set as well via the right click menu.

[kevinleecarr-okta]

Ideally, I could select a list of files from the source control tab and create a working set from the selection or add the selected files to an existing working set.

[JodieM]

When will we have Managed Package support in Org Browser please? Following on from #862 where Nathan said it was "not something that will be done right away" but we are now 16 months past that date.

[JodieM]

@ntotten and @clairebianchi both of you have said recently the words "all your org metadata" is in Org Browser. Does this mean that this managed metadata issue has been fixed or will be fixed soon?

[richclark808]

Was hoping to use the Source Tracking sandbox options to treat prod org sandboxes the same as sandboxes, or at least not to have to create a package.xml (which was very easy to do in Force.com IDE and MavensMate ahem). So really need the working sets to plug this gap, thought trying out this extension (https://marketplace.visualstudio.com/items?itemName=VignaeshRamA.sfdx-package-xml-generator) until we have an official solution.

There is fundamentally a need for a 'get everything command' which doesn't rely on the package.xml (or a working set) being maintained. Great that I can exclude stuff, but this isn't the use case for so many people.

So far all the tools have focussed on package.xml, but I have dozens of users who want to pull from a prod/sandbox, make changes in a scratch org, then deploy using metadata api into a sandbox for testing. Just very very clunky and not worth the effort today. Hoping this comes soon to fix this. Try explaining this all to a AWS or Azure developer!

[AnanyaJha]

Hi @rclark-provar thanks for sharing this feedback with us a while ago! In this past iteration, we added the ability to generate a package.xml manifest file automatically through the Manifest Builder and we'll continue to make improvements around this experience of interacting with the metadata in your org.
As part of this work, I'd like to understand a bit more about what you're looking for in a 'get everything command'? Is this something you still need and have you found a workaround in the time since your comment was posted? Looking forward to hearing from you!

[JodieM]

@AnanyaJha I just tried to use the Manifest Builder on a brand new project and it did nothing. It requires the full file and folder structure of the org to be in VS Code in the first place and that completely defeats the purpose. We need a way to download the FULL metadata of an org, and / or select which metadata components to exclude via a visual tool - eg exactly what MavensMate used to provide many years ago. I know tools like Illuminated Cloud does it, but we need this capability in VSCode . It really makes VSCode impenetrable to use for Admins and people starting with VSCode and SFDX.

[peternoges]

Theres a way to do something similar. There's the right-click filetree action, "generate manifest" as well as similar sf command for generating package.xml manifest from filepath(s). You can select multiple files from the filepath and right click and make a manifest from them. These exported/generated manifests files are basically the same as the working set concept.