Add suggested correction to PSMissingModuleManifestField rule

[kapilmb]

The rule is triggered whenever a module manifest doesn't contain module version. This commit sets the suggestedCorrections property to suggest a ModuleVersion field to the manifest.

Resolves #512

---

This change is

[raghushantha]

Reviewed 4 of 4 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[raghushantha]

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable

[lzybkr]

Review status: all files reviewed at latest revision, 2 unresolved discussions, all commit checks successful.

---

Rules/MissingModuleManifestField.cs, line 78 [r1] (raw file):
I don't think you'll want this longer term - we can produce a HashtableAst in a configuration that doesn't start with @{ and you may want to have a similar diagnostic there too.

---

Rules/MissingModuleManifestField.cs, line 86 [r1] (raw file):
I think the correction should go at the end, not the start.

---

Comments from Reviewable

[daviwil]

Since this rule seems to be specifically about module version, should you make the rule name specific to that as well or are you planning to look for other missing fields in the future?

---

Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

Tests/Rules/AvoidUnloadableModuleOrMissingRequiredFieldInManifest.tests.ps1, line 29 [r1] (raw file):
Should you use $expectedCorrections in the 'Should' check here just for consistency?

---

Comments from Reviewable

[KirkMunro]

My hopes (and what I believe was the intent) was that this rule would identify missing fields in future versions as well.

---

Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

Comments from Reviewable

[kapilmb]

According to Test-ModuleManifest, a module manifest missing only the ModuleVersion field is an invalid manifest. And as of now this rule is just trying to warn the user of the invalidity of the module. However, going forward we would like to add other fields to this rule which can encode the "best practices" while authoring a module.

---

Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

Rules/MissingModuleManifestField.cs, line 78 [r1] (raw file):
I will add that diagnostic - Can you please point me the resource where I can find the other ways I can produce a HashtableAst?

---

Rules/MissingModuleManifestField.cs, line 86 [r1] (raw file):
Sorry, but I am not able to see through as to why it should go at the end. Can you please explain why the correction should go at the end and not the start?

---

Comments from Reviewable

[kapilmb]

Rules/MissingModuleManifestField.cs, line 86 [r1] (raw file):
I can think of this - the editor doesn't need to displace all the text if we put the correction at the end. Is there any other reason why the correction should go at the end?

---

Comments from Reviewable

[lzybkr]

Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

Rules/MissingModuleManifestField.cs, line 86 [r1] (raw file):
I had 2 thoughts - thinking generally about correcting missing entries in a hashtable - that appending is probably better than inserting - my thinking is that the user puts the most important stuff first, we're overriding that. The second thought was that I rarely see ModuleVersion as the first entry in a module manifest. It does happen, but it's not the norm.

---

Comments from Reviewable

[kapilmb]

@raghushantha @lzybkr @daviwil Thanks for the review.