Add a new gulp task to validate the manifest for store publishing

[waldekmastykarz]

Add a new gulp task in the generated gulpfile.js to validate the manifest for all information required to publish the add-in in the Office Store.

[waldekmastykarz]

Shall I pick it up?

[jthake]

yes, as it appears that validation for store is more strict than for enterprise. having the option would be useful. how can we maintain the two rulesets easily though?

[waldekmastykarz]

The idea that I had was to keep the existing validate-xml task intact and then add another one called validate-forstore or something like that that would validate the XML and then scan the additional rules.

[waldekmastykarz]

Adding @patbuergin and @Dealmaster13 from Microsoft to the thread.

Looking at the current Office Store publishing guidelines published at https://msdn.microsoft.com/en-us/library/office/jj220035.aspx I came up with the following list of checks based on the manifest:

4.12.1. Add-ins for Word using manifest schema v1.1 and Office.js v1.1 must support Word Online.
5.10. You must specify an icon for your app or add-in in your add-in package or manifest, and that the icon must be correctly sized and formatted. (we already check for an https URL and we need to extend it with a check for the file extension in the URL as described in #112)
7.4.3. You must specify language support for your add-in in your add-in's manifest.
7.9. Valid manifest (XML validation which we already have)
7.16. You must specify a valid Support URL in the SupportURL element of your Office Add-in manifest.

Do you guys think it would be sufficient if we checked for these items or would we need to do more than that to help developers publish their add-ins in the Office Store?

[patbuergin-zz]

Most importantly, we should check the following:

• The manifest uses schema v1.1 (10.9)
• The index file contains a reference to https://appsforoffice.microsoft.com/lib/1.1/hosted/office.js (7.15 & 10.9)
• The value of SourceLocation is prefixed with https:// (5.7)
• The version tag adheres to the following pattern ^\d+\.\d+\.\d+\.\d+$, e.g. 1.0.2.15 (10.3)

I think we can further help developers by pointing them to the validation guidelines whenever gulp finishes successfully, as there are several content-based policies to consider as well.

[andrewconnell]

IMHO anything that can be programmatically checked that is a requirement or would cause a rejection from being accepted in the Office Store should be in this validation task validate-forstore

The validate-xml should just validate for well-formed XML & validate against the published XSD

[waldekmastykarz]

@patbuergin these are great suggestions!
Isn't 10.3 already enforced by the XSD with the Version type?

@andrewconnell if we'd like to keep the validate-xml task limited to only validating XML against XSD then we would need another task to do the checks for the App Catalog such as the one on icon URL that we already have now.
How about we do it like this:

• validate-xml: XML validation against XSD only
• validate-forappcatalog - validate-xml + everything else required for publishing in the App Catalog (or should we call it validate-foraddincatalog @jthake?)
• validate-forstore - validate-xml + validate-forappcatalog + all additional rules we discussed above
• validate - parent task to perform all validations (currently the same as validate-forstore but could be more in the future)

[andrewconnell]

A thought… what’s the reason for validating the XML against the XSD if there are additional requirements for addin catalog & store? If you don’t meet those two bars, then it’s worthless because you can’t use it… right?

[waldekmastykarz]

That's correct. We could as well change it to a function that we can call from both validation tasks rather than keeping it as a separate task. Is that the direction that you were thinking?

[andrewconnell]

I no micromanage… you smart cookie so if you’re taking it, I let you implement how you best see fit :)

[waldekmastykarz]

👍 :)