Rather than putting this below an else, I think the best option is to invert the if condition above, like:

if (!SessionStateUtilities.MatchesAnyWildcardPattern(func.Name, functionPatterns, noPatternsSpecified))
{
    string manifestFilename = Path.GetFileName(cmdlet.Context.PreviousModuleProcessed);
    string moduleFilename = Path.GetFileName(sourceModule.Path);
    message = StringUtil.Format(Modules.NotImportingFunction, func.Name, moduleFilename, manifestFilename);
    cmdlet.WriteVerbose(message);
    return;
}

// Golden path here

@rjmholt Yep I'm still on this. I've just been pretty busy lately :).

@rjmholt

Hmmm this doesn't actually work quite the way I hoped it would. Basically when loading the root module specified in a module manifest file there are two calls made to ImportFunctions().

• The first call is made as a consequence of calling LoadModule which will try to export AND import its members (thus the first call to ImportFunctions without any specified pattern so it says it can't export via the manifest file).
• The second call happens as a consequence of ImportModuleMembers().

The presence of these two calls means we get extra log messages which we don't want. I'm going to look into how to get around this.

Yeah, the duplicate/subsequent calling of methods is a big problem in the module cmdlets (chiefly in ModuleCmdletBase). It gets quite complicated, and particularly when RootModule is specified, it discards a lot of information and calls itself recursively.

The potential for regressions is large, which is why nobody's refactored it yet. When I've found time, I've tried to write tests that will eventually cover enough of the functionality to rewrite this functionality properly. Certainly things have broken in this area before.

So essentially, don't feel too compelled to pursue this if it gets too complex. There are a number of outstanding work items in this part of the code that have been avoided for being too risky or too time consuming while it's in its present state.

Thanks for the context. In that case i will probably close this pr in the coming days if I don't find a way around it. At least this tells me that there is work to be done in this part of the codebase (testing and refactoring).

Definitely. It's one of the oldest parts of the codebase and very central to a lot of functionality (in subtle ways), so generally the strategy is to build out extensive testing for it and I'm hoping once we have regression testing in place we can refactor the logic into more contained, module pieces.

Thanks for looking into this btw @pougetat -- we're always grateful for contributors like yourself.