Source code documentation

[Hjaf]

Is there any documentation out there that explains or provides schemas for various xml and json files in unpacked solutions?

From what I have found so far in the documentation, it seems like we are only able to infer the source code structure for solutions. We can can only partially utilize git history for code reviews and pull-requests, as long as we don't have the full picture of the structure. I believe that if we knew what part of the code is actively altered by the developer in power apps/automate studio, it would make pull-requests and code reviews viable and effective for power platform solutions.

[parvezghumra]

@Hjaf If you're referring to a full schema definition of the unpacked solutions, I haven't seen anything of this nature. If it is available I would imagine it may not always be 100% up to date, as when I examine my unpacked solutions commit history in Git, very often I will find changes that were unexpected by the developers/makers, and the only possible explanation I could think of was a a potential change released by Microsoft to the solution framework/structure itself or the tooling used to export/unpack solutions.

However, if you review the entire folder structure and contents of unpacked solutions, its possible to get at least a high level understanding of some of the files and their contents correspond to the actual solution components.

I do agree though, it would be great if there was some formal reference document available explaining the full schema of unpacked solutions and how each file and their contents correlate to solution components.

[Hjaf]

@parvezghumra Thanks for your insight (sorry for the late reply by the way) 😄

How are the contributors to microsoft/powerplatform-build-tools and microsoft/powerplatform-actions able to produce all these actions and functions? These are both Microsoft repositories, surely there must be some kind of collaboration with the platform developers in place. I assume there is some kind of internal guarantee or contract, which would allow documenting this structure at some level, albeit at a slightly higher level than I'd prefer.

It seems that code-reviews can be significantly improved by pruning just some of the metadata and assets that isn't required for building and deploying the solutions. But even though it's possible to make the code reasonably clean with some kind of exploratory elimination process, we would obviously need something more concrete and reliable than this 🤔