bicep-registry-modules VS PSDocs

We have a separate parameter file for every landing zone instance (our implementation is a bare-bones CAF landing zone, kinda like https://github.com/Azure/bicep-registry-modules/tree/main/modules/lz/sub-vending, which is avaible from bicep public registry), where instance is for example a separate environment (dev/test/prod). This parameter file only represents the configuration, so things like subnets, nsgs and so on, and it has nothing to do with the landing zone implementation as such.

As you point out, it is another layer of abstraction that can make it more complex. Specifically it will add a pain point with the replication of the modules from /ResourceModules to the private repo. (I dont have a good solution for that at the moment) Microsoft has a public container registry (https://github.com/Azure/bicep-registry-modules) that someday may be updated to contain everything in /ResourceModules

Still a work in progress, but the official bicep registry - https://github.com/Azure/bicep-registry-modules

For Pull Requests, it compiles bicep into ARM templates and runs PSDocs for them an accompaying json file that holds versioning information and, document title and some additional information. Then it looks for ./test/module.test.bicep -file (which is just a copy of a suitable test suite from ResourceModules) and runs psrule against that. For runs triggered from main-branch, it queues the module publishing pipeline for every changed module.bicep found.