Invalid Command Line Switch Parameters in SPFx Yeoman Generator v1.8.0.0

Home » SharePoint Development » Invalid Command Line Switch Parameters in SPFx Yeoman Generator v1.8.0.0

Invalid Command Line Switch Parameters in SPFx Yeoman Generator v1.8.0.0

Posted on

When we built the Visual Studio Extension for SharePoint Framework, we made a conscious decision not to try and replicate the behavior of the underlying Yeoman generator but rather to execute it silently in the background then take the results and put them into a properly structured VS solution. This has worked rather well (more than 11,000 downloads in the VS Marketplace to date), mostly because we can quickly refactor and facilitate changes the product team makes to the generator as we are just placing a wrapper around the same commands developers can issue manually should they choose to do so.

In the v1.7.0.0 release, the product team normalized the parameter naming convention and introduced two new switches: –skip-feature-deployment and –is-domain-isolated. You probably know these better by the option labels of “Do you want to allow the tenant admin the choice of being able to deploy the solution to all sites immediately without running any feature deployment or adding apps in sites?” and “Will the components in the solution require permissions to access web APIs that are unique and not shared with other components in the tenant?”.

I opened a bug for that release when I discovered that the command-line switches only produce the desired result if the user wants the boolean value of true to be inserted into the package-solution.json file. Omitting the flags causes the user to be prompted by the generator, which violates the silent execution objective of the command line switches. Any values passed as a parameter to either switch will be inserted into package-solution.json as a string value.

Take the following example:

yo @microsoft/sharepoint –solution-name “MySPFxProject1” –component-name “Test 1” –component-description “Test 1” –component-type “webpart” –framework “none” –skip-install –environment “spo” –package-manager “npm” –skip-feature-deployment –is-domain-isolated –skip-cache

This produces the correct package-solution.json:

{
“$schema”: “https://developer.microsoft.com/json-schemas/spfx-build/package-solution.schema.json“,
“solution”: {
“name”: “my-sp-fx-project-1-client-side-solution”,
“id”: “734d14ab-507b-4664-83d1-c15ea7a4323b”,
“version”: “1.0.0.0”,
“includeClientSideAssets”: true,
“skipFeatureDeployment”: true,
“isDomainIsolated”: true
},
“paths”: {
“zippedPackage”: “solution/my-sp-fx-project-1.sppkg”
}
}

However, omitting either switch causes the generator to prompt for input, which it should not do. Instead, it should insert a false value into package-solution.json. If, as the documentation suggests, a string value of “false” is added as a parameter, it is not parsed to produce a boolean result but rather inserted as a string. Take the following example:

yo @microsoft/sharepoint –solution-name “MySPFxProject1” –component-name “Test 1” –component-description “Test 1” –component-type “webpart” –framework “none” –skip-install –environment “spo” –package-manager “npm” –skip-feature-deployment false –is-domain-isolated false –skip-cache

This produces the following invalid result:

{
“$schema”: “https://developer.microsoft.com/json-schemas/spfx-build/package-solution.schema.json“,
“solution”: {
“name”: “my-sp-fx-project-1-client-side-solution”,
“id”: “734d14ab-507b-4664-83d1-c15ea7a4323b”,
“version”: “1.0.0.0”,
“includeClientSideAssets”: true,
“skipFeatureDeployment”: “false”,
“isDomainIsolated”: “false”
},
“paths”: {
“zippedPackage”: “solution/my-sp-fx-project-1.sppkg”
}
}

The same is true of any string value, such as “false”, “n”, n, no, $false, or anything else – the value is simply converted to a string and the project fails to build because the gulp task is looking for a boolean value instead of a string. Not only is this the incorrect behavior and contrary to the official documentation but it also caused the VS Extension to produce incorrect results. This issue appeared to have been fixed in v1.7.1.0 so it was closed and we released an updated version of the extension in January of 2019 (even though the documentation was never updated to reflect their proper utilization as switches). Unfortunately, the problem seems to have reappeared in the v1.8.0.0 release of the generator. At present, it is not possible to scaffold a correctly-structured project that requires a false value to be set for either parameter without manually editing the package-solution.json file. As a workaround, run the commands with both switches included then edit the file and change them to false (or set the values to “false” and then simply remove the double-quotes around each value in the generated markup).

The issue has been raised again and we will document this in the interim v1.8.0.0 release of the extension. Hopefully, the product team will release a permanent fix so scaffolded projects can be built immediately after creation without manual intervention.