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.
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
- 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
- Added a reference to the local typescript tsdk in
.vscode/settings.jsonfor 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:
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
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.
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::
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 targetted 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.comments powered by Disqus