force:source:retrieve on top level produces different source than when run on subdirectories
- Dominant language
- No language data
- Stars
- 571
- Forks
- 80
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 3
Description
### Summary
Working on a Gen-1 Manage Package, specifically with permission sets, the source content depends on how it's retrieved from the Org.
Running `force:source:retrieve` with `--sourcepath` pointing to the top level project (`force-app/main/default`) produces slightly different source than if run on a sub-directory (`force-app/main/default/permissionsets`). Both sets of source are functionally equivalent, but the first version produces source with "extra" permission definitions whereas the second version produces a cleaner set of source with just the settings originally specified in the permission sets.
### Steps To Reproduce:
**Repository to reproduce:** [dreamhouse-lwc](https://github.com/dreamhouseapp/dreamhouse-lwc)
> Should I have forked that repo? The steps below are sufficient to reproduce this issue, but I can fork and push what I did to reproduce (just step 1).
1. Create copy of `dreamhouse.permissionset-meta.xml` and remove all settings for `Property__c` (delete lines 204-219, 191-199, 50-181, 7-14)
1. Push new permission set to the Org
1. Run `sfdx force:source:retrieve --sourcepath ".\force-app\main\default\permissionsets"`, note the contents of the new permission set go unchanged.
1. Run `sfdx force:source:retrieve --sourcepath ".\force-app\main\default"`, note the contents of the new permission set are updated with all the implicit settings for `Property__c`, which were originally unspecified.
### Expected result
Source managed by SFDX doesn't depend on how it's retrieved from the Org.
### Actual result
Source depends on how it's retrieved from the Org.
### Additional information
> Note: We're working a blended a workflow between Gen 2 and Gen 1. Our Managed Package is Gen 1, but we're trying to transition to developing in Scratch Orgs and then sync to our Gen 1 Dev Org for the release process.
**SFDX CLI Version**(to find the version of the CLI engine run sfdx --version):
sfdx-cli/7.58.2-937f666ed4 win32-x64 node-v10.15.3
**SFDX plugin Version**(to find the version of the CLI plugin run sfdx plugins --core)
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.2.3 (core)
@oclif/plugin-help 2.2.3 (core)
@oclif/plugin-not-found 1.2.3 (core)
@oclif/plugin-plugins 1.7.9 (core)
@oclif/plugin-update 1.3.9 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-diff 0.0.6
@salesforce/sfdx-trust 3.0.7 (core)
analytics 1.7.1 (core)
generator 1.1.2 (core)
salesforcedx 48.14.3 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.5 (core)
├─ salesforcedx-templates 48.17.0 (core)
└─ salesforce-alm 48.15.0 (core)
sfdx-cli 7.58.2 (core)
shane-sfdx-plugins 4.28.2
**OS and version**:
Windows 10 Pro Version 1909 (OS Build 18363.836)
Contributor guide
Assessment
This issue has not been assessed yet.