Should DSC Resource Manifests allow '*' in *ToExport and Include DscResourcesToExport

[PlagueHO]

This is something for community discussion and has several parts:

1. Should we allow '*' in *ToExport Properties in DSC Resource module manifests - e.g.

FunctionsToExport = '*'
CmdletsToExport = '*'
VariablesToExport = '*'
AliasesToExport = '*'
DscResourcesToExport = '*'

If not, then I think we could look at these tasks:

• Add a guideline?
• Add DSCResource.Tests (opt-in) to check?
• Update the module template

2. Should we include DscResourcesToExport in Manifest that is not set to '*'?

DscResourcesToExport = @(
    'MyResource1',
    'MyResource2'
)

If so, then I think we could look at these tasks:

• Add a guideline?
• Add DSCResource.Tests (opt-in) to check?
• Update the module template

[johlju]

I like this, so I'm for having an opt-in check for this so we don't miss adding a (new) resource to the export list. Nad of course, updating any documentation and template as needed.

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[gaelcolas]

I agree with forbidding the usage of *, but at the same time we need to provide the tooling that helps managing this.
The opt-in PSSSA rule would be great, but maybe we (I?) should focus on build scripts that just take care of this?

[PlagueHO]

I've added tests in other PS projects of mine to test this and other manifest issues. So might be able to port those across fairly easily with an opt-in rule. Not sure PSSA will work here because it doesn't work on .PSD1 files as IIRC. Could be wrong though.

[johlju]

Would be great if you could port the tests so this were opt-in. Thought of this the other day as I forgot to do this in those repos I maintain. Having an opt-in rule reminding to opt-in would be great! :)

[gaelcolas]

Maybe we should change the opt-in to opt-out... so that any drift from guidelines is conscious and visible?

[johlju]

We don’t want to break any repositories so they can’t be released since there are no one normally available to fix any CI problems. There for all tests we add are opt-in.

[PlagueHO]

We did originally try the opt-out model on some rules a couple of years back but had to back it out as it broke many repos. We also had non resource kit DSC resource module owners that use DSCResource.Tests and they may not fully adhere to DSC resource kit guidelines. Especially as there were many repos with no maintainers who could fix the potential violations. If it were just the repos I maintain I'd be good with opt-out 😁