SharePoint Framework v1.1.1 - Sign of On-Prem SPFx to Come?

In April, I showed you in another blog post how to pick apart and see what changed with the SharePoint Framework Yeoman generator with a recent update. With the developer preview release of extensions earlier this month, Microsoft also updated the generator to support these new types.

This generator has quite a few other changes in it that we hadn’t seen before… and you might find interesting as well! Not only that, but there’s a hint of what’s possible to come with on-premises SharePoint Framework.

The current version of the generator is 1.1.1, but that was really just a patch to a previous version.

What Changed in version 1.1.0

Version 1.1.0 was published on May 25, 2017 and included quite a few changes, although Microsoft listed them as minor changes in their change log:

• Added support for safeWithCustomScriptDisabled manifest property
• Fixed the hard-coded “helloWorld” class name in the web part generator templates
• Improved the question sequence so that the framework selection applies to individual components, rather than being a solution-wide setting
• Updated default manifests to use "version": "*" to automatically get the version from the package.json
• Added a reference to the local typescript tsdk in .vscode/settings.json for improved IntelliSense in Visual Studio Code

This is the update that introduced the extensions templates to the generator in addition to the other things listed above.

Microsoft also introduced a fairly significant refactoring to the organization of the project as you can see from the following figure:

What Changed in version 1.1.1

Version 1.1.1 was published on June 8, 2017. It seems to have only included one minor change:

• Adding a missing sp-application-base dependency

A Sign of On-Premises SharePoint Framework To Come?

One thing that did stand out to me is the introduction of two sub generators within the project that are not exposed at this time.

First you have to understand how Yeoman works. The way a Yeoman generator works is it contains one or more sub generators. The base generator (found in the app folder), may call other generators. In the context of the SharePoint Framework generator, a sub generator is used for each variation of project type.

Looking at the picture above, you see folders for applicationCustomizer, commandSet, webpart any many others within the lib folder.

Two folders stood out to me: onPremComponent & onPremWebpart.

When you look at the onPremComponent, you can see in the generated JavaScript code (clearly they are authoring the generator in TypeScript… Microsoft just isn’t including it in the distributed generator) it is basically a blocker as it indicates that on-premises SPFx will only support web parts for onPremises deployments… something we knew about:

function defineOptions(generator) {
    generator.option('componentType', {
        description: "The type of component. Currently \"webpart\" is the only option.",
        type: String
    });
    OnPremWebpart.defineOptions(generator);
}

Looking at the onPremWebpart sub generator, you can see the different types of projects that will be provisioned within the templates. These are the different flavors of client-side web parts you can create.

I looked at the code for these and compared it using my favorite diff tool against the sub generators we have had in SPFx for a while now and wasn’t able to find any differences.

A little more investigating yielded another few interesting lines of code. Look at the base sub generator in the app folder, specifically the index.js file on lines 48-81 that I copied here::

AppGenerator.prototype.prompting = function () {
    // Configure the solution root folder before other composition.
    if (this.context.creatingSolution) {
        // Create solution because not in a solution folder
        this.log("Let's create a new SharePoint solution.");
        // Config destination root before composition.
        Solution.composeWith(this, {
            'skip-install': this.options['skip-install'],
            solutionName: this.options.solutionName,
            // This will prevent the solution generator from asking the environment question.
            // TODO: Task 367695 Remove hardcoded 'spo' string that prevents Yeoman Generator
            // from asking about the environment type
            environment: 'spo'
        });
    }
};
AppGenerator.prototype.configuring = function () {
    // tslint:disable-next-line:no-any
    var options = {
        'skip-install': this.options['skip-install'],
        componentType: this.configuration.environment === 'onprem' ? 'webpart' : this.options.componentType,
        extensionType: undefined,
        creatingSolution: true,
        framework: this.options.framework,
        componentName: this.options.componentName,
        componentDescription: this.options.componentDescription
    };
    if (this.configuration.environment === 'onprem') {
        OnPremComponent.composeWith(this, options);
    }
    else {
        Component.composeWith(this, options);
    }
};

Interesting… we see hard coded references to spo (presumabily SharePoint Online) & onprem.

I wonder why the distinction between the two environments in the generator. Does this mean there’s a chance that things I build will be targeted for two different versions of SharePoint, either SharePoint Online and SharePoint on-premises? Surely not… well I surely hope not.

But it does make me wonder why there’s a distinction in the generator for it.

None of this affects us today nor has Microsoft talked at all about this. I do find it interested it made it into the production generator though… maybe that was an oversight. At any rate, this might be something to keep an eye on as we get closer to SharePoint Server 2016 Feature Pack 2 which will add the SharePoint Framework to on-premises deployments.