feat: handle decomposed type

[scolladon]

Explain your changes

---

Goal of this pull request is to handle the new decomposed type discussed here and released here

We have to make the distinction between those kind of types :

• Decomposed file that represent a metadata in itself (and could be deployed standalone like workflow rule)

  • it can appear alone in the deployable file
  • it can appear alone in the package.xml

• Decomposed file that represent a part of a metadata (and does not represent a metadata kind like field permission) (exemple: Profile)

  • it can appear alone in the deployable file as the cli will be able to recompose the file
  • it cannot appear in the package.xml as it does not represent a metadata type
  • it can be deployed partially, meaning it will only change what is inside the file deployed

• Decomposed file same as the previous one but it cannot be deployed partially and requires everything else to deployed as well (exemple: PermissionSet)

• [x] Jest tests added to cover the fix.

• [x] NUT tests added to cover the fix.

• [x] E2E tests added to cover the fix.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (94f1a5a) to head (4d4487f).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #825 +/- ## ========================================= Coverage 100.00% 100.00% ========================================= Files 37 39 +2 Lines 1044 1068 +24 Branches 113 115 +2 ========================================= + Hits 1044 1068 +24 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[scolladon]

It's a fairly big refactoring, so once merged I would suggest to leave it as a release candidate for a while to test it extensively 😄

I agree @mehdisfdc, but before we should put the current latest to the same version as the current latest-rc. It contains also a pretty big refactoring around how we interact with git. This refactoring has been in rc for at least a month and we only have one issue very very specific that is very hard to reproduce (windows specific, git version specific and I suspect hardware specific as well, with a very large repository). Pushing the current rc version to a more broader audience would help us make sure it is fairly stable or have more material to find the root cause of this issue (and we can still put stable to the previous version).

What I propose :

• Next monday, make latest point to the same version as rc
• Fix issues related to this new latest
• The monday after that (if stabilized), merge this PR and release a new rc version with this refactoring (I prefer merging after because I prefer integrate fixes from main inside this PR instead of fixing the main branch containing it as it is a big change in some area and it could cloud the investigation)

Apart from that, doing this refactoring made me realized we have a built a big mechanism and logic around metadata, which seems to be built (not really long ago) inside SDR... I really consider refactoring our implementation using this library instead of our in house metadata engine in order to simplify a lot our implementation. I'll try to poke around the next days and see if there are any blocking issue, if it goes well I'll propose another big PR

[github-actions[bot]]

Published under beta-825 npm channel.

$ sfdx plugins:install sfdx-git-delta@beta-825

[codeclimate[bot]]

Code Climate has analyzed commit 4d4487fb and detected 0 issues on this pull request.

View more on Code Climate.

[github-actions[bot]]

Published under dev-825 npm channel.

$ sfdx plugins:install sfdx-git-delta@dev-825

[github-actions[bot]]

Shipped in release v5.39.0. You can install the new version using the version number or the latest-rc channel

$ sfdx plugins:install sfdx-git-delta@latest-rc
$ sfdx plugins:install sfdx-git-delta@v5.39.0

Happy incremental deployment!