Reference message: The member 'ModuleVersion' is not present in the module manifest. This member must exist and be assigned a version number of the form 'n.n.n.n'. Add the missing member to the file '...'.
It appears that the 'PSMissingModuleManifestField' rule is applied to all PSD1 files, which in many cases falsely identifies these files as Module manifests, which is not the case. Generically PSD1 files are just PowerShell Data files and can be put use in different ways. One example is when declaring and importing localized data related to script internationalization (see: https://technet.microsoft.com/en-us/library/hh847854.aspx).
I suggest modifying the test to determine that if a [FileName].psd1 file is identified, first look for a [FileName].psm1 file in the same folder, and if found test this rule.
You can't just check for the presence of psm1 though. psd1 files may define module manifests with no root module. They may also be manifests associated with binary modules (dlls). And they may refer to psm1 files with different names. With all of those scenarios in mind, this test simply cannot check for the presence of a matching psm1 file in the same folder before running this rule.
It would be better to look at the contents of the psd1 file and determine what rules apply based on the contents. For example, the rule could look at the keys defined in the hashtable and if the keys collection is a subset of the keys used in module manifests, then the module manifest rules could be applied.
I find this issue ironic because I'm using a PSD1 file for the script analyzer settings file that will ship with the next version of the PowerShell extension for VSCode. :-) Users will be able to customize the extension's PSScriptAnalyzerProfile.psd1 "global" file or use the .vscode\settings.json file in their workspace to override the default settings with their own settings file.
Recently I wrote tests for verifying psd1 internationalization files - in this moment tests are specific for Format-Pester but in near future I'll try generalize them.
Some test are based on the comparison between a basic language (en-US) file and an other language file. Maybe part of those test can be reused to resolve that issue?
My proposal is based on the suggesion of @iainbrighton .
@it-praktyk Can you please explain your comparison logic in more detail OR if you can provide a link to the test files that would be helpful too.
I'm not sure if my proposal is OK but I explain it bit deeper.
# culture="en-US"
ConvertFrom-StringData @'
msg00 = 1.3.0
msg01 = Table of Contents
msg02 = Total Tests
msg03 = Passed Tests
Test similar to this can be used (?).
Most helpful comment
You can't just check for the presence of psm1 though. psd1 files may define module manifests with no root module. They may also be manifests associated with binary modules (dlls). And they may refer to psm1 files with different names. With all of those scenarios in mind, this test simply cannot check for the presence of a matching psm1 file in the same folder before running this rule.
It would be better to look at the contents of the psd1 file and determine what rules apply based on the contents. For example, the rule could look at the keys defined in the hashtable and if the keys collection is a subset of the keys used in module manifests, then the module manifest rules could be applied.