Tag Archives: SharePoint Framework

SPFx packaging: Sharing code between many web parts or extensions

When developing SharePoint Framework components (web parts and extensions) you may release a single one to an environment and be done with it. Or more likely you’ll be creating multiple web parts and extensions and will need to decide how to approach SPFx packaging.

Things to consider when packaging SPFx components

  • How do I share my code between components?
  • How do I share library code between components?
  • How do ensure that components use the same version of the SharePoint Framework?
  • How do I version dependencies of the components?
  • How do I upgrade components?
  • What is the development/test environment like?

All these questions really boil down to a single question:

Do you a create a multi-component SPFx project or have a project for each component?

* SPOILER *

I have concluded that the default approach to SPFx packaging should be to include all components into a single multi-component project. Avoid creating multiple packages where possible. Depending on the scale of the development team there may be some scenarios where this is not appropriate, in which case create as few multi-component projects as are necessary. Furthermore, I recommend creating a single multi-component JS bundle file for all web parts in package (a multi-component bundle), rather than the default approach of having a JS file for each component.

SPFx config.json, multiple web parts will be packaged as a single bundle as part of a single package

Terminology

Multi-component project/package: SPFx packaging such that a single sppkg file is produced which deploys multiple SPFx web parts or extensions.
Multi-component bundle: Only available within the context of a multi-component project, a multi-component bundle includes the JS required for all components as a single file rather than a file for each component.

Just do it

So take my word for it, add all your SPFx components to a single package and create multi-component bundles. To add additional web parts to an existing project just run the Yeoman generator again in the same folder location. Elio Struyf has a post about multi-component bundles and I’m sure that there will be official guidance release very shortly.

Or perhaps you’d like me to explain my rationale, the benefits, and where this approach may not meet your needs. In which case, please read on..

What you sacrifice by having a single project

Firstly, let’s discuss what is sacrificed by packaging SPFx components into a single sppkg package?

  1. You can no longer install or upgrade components individually. (However, the new site collection scoped app catalog may assist with this.)
  2. Depending on your development environment, it may be easier to govern source code and DevOps processes during development and test. For example if you have different teams working different web parts.
  3. During development you can build and deploy individual components which may lead to time savings if/when the volume of components becomes large. (In these cases the gulp tool chain could be modified to meet requirements.)

What you gain by having a single project

If the above list of sacrifices aren’t deal breakers then there are many benefits to be had by taking this approach.

  • Sharing code between SPFx components is trivial. Sharing code between packages is hard.
  • Deployment and upgrade is trivial especially with tenant-scoped deployment – just deploy a single package to the app catalogue and you are done.
  • The risk of having multiple web parts using different versions of the SharePoint Framework is avoided.
  • The risk of having multiple versions of third partly libraries loaded is greatly reduced.
  • Total payload of components will be much smaller due to reduced duplication of shared code, library code (especially Office UI Fabric), and the framework itself due to multi-component bundling. Sub-optimal usage of external references, static vs dynamic import statements, and the bloat that some recommended frameworks currently inflict (Office UI Fabric React…) can lead to very substantial page weight increases. By using a multi-component bundle the worst case scenarios are avoided as in most cases these issues will impact a solution once for each bundle.
  • Versioning of shared code is trivial because you don’t have to it. Internal dependencies are including the bundle and external dependencies are referenced to only once. The framework itself handles the component versioning for you.

And finally…

I’d be particularly interested to hear from people who have found strong reasons to package components individually because currently I believe that the benefits of multi-component SPFx packaging outweighs the benefits in nearly all scenarios.

Paul.

Ignite 2017 Updates Webinar

I recently joined Jeremy Thake of Hyperfish and my colleague David Bowman to host a webinar focussed mainly on some our favourite announcements that came out of Ignite 2017. I have a list of my recommended viewing from the conference at the end of this post.

The webinar was to have primarily a non-technical audience so it doesn’t get deep into many particularly technical topics but it does give a good overview of some of more important announcements of Ignite 2017, in my humble opinion.

Ignite 2017 banner image

You can view the webinar here: Harness the power of Office 365

I discuss

  • Required information fields
  • Files that need attention view
  • Bulk update of file metadata
  • Metadata prompt on file upload
  • Filter panel updates
  • Improving support for large lists and libraries
  • Column formatters
  • Hub sites
  • New Yammer web part
  • Custom modern themes
  • Site designs
  • Multi-geo
  • Groupify – create Office 365 groups from existing team sites
  • Group naming policies and management
  • Microsoft Teams Admin Centre
  • Microsoft Teams data storage and information protection

Ignite 2017: Recommend viewing:

Hope this helps you get up to date in record time!

Paul.

A history of extensibility in SharePoint and how to choose a model

I recently wrote a post for my employer about the recent history of SharePoint extensibility models. It also touches on how we as company settled on the model with which we are currently delivering our Intranet/Digital-Workplace solution. I discuss the Feature Framework, Farm and Sandboxed Solutions, SharePoint Add-in Model, SharePoint Framework, Remote Provisioning, and more.

Check it out here: A history of extensibility in SharePoint and how Fresh chose a model

SharePoint extensibility model, Generic image

tslint, VS Code, and the SharePoint Framework

The new SharePoint Framework (SPFx) is currently in developer preview. In order to really get into it and start making great new web parts a developer needs to get a handle on TypeScript. The initial preview iteration of the SPFx shipped with very strict linting rules (tslint) and it forced (in)experienced developers to follow many best practices regarding not just typescript but es6/es2015 conventions as well. This was done by reporting linting errors as build failures as part of the Glup build chain.

Later drops of the SharePoint Framework have relaxed these linting rules but it is still less than ideal only being prompted about these issues at transpile/compile-time. The set of linting rules that is used in the build process is defined in a tslint.json file within the root config folder.

The tslint file that is provided by the SPFx generator
The tslint file that is provided by the SPFx generator

When it comes to developing SPFx web parts I have found Visual Studio Code to be great, as it is lightweight has an integrated terminal and github support and has extensions – noticeably a nice tslint extension. Unfortunately this extension does not support the JSON format nor all of the rules specified in tslint file provided by SPFx generator.

The TSLint VS Code extension
The TSLint VS Code extension

So here it is, my SPFx tslint file for use in VS Code. Just drop this file in the root of your src directory.

Add this tslint file to the root of the src folder
Add this tslint file to the root of the src folder

The following file is based on a core set of rules from SPFx Drop 2 with the incompatible rules removed and I’ve taken some liberty by adding my own preferred rules. Of course you can change these as you need, a list of the rules which the extension supports can be found here. I have also included an ‘extended’ version of the tslint file that is provided in the config folder further below.

tslint.json in the src folder:

tslint.json in the config folder:

Paul.

SharePoint Framework Dev Kitchen Winner

Brag: I was invited to the SharePoint Framework Dev Kitchen last month where they held a hackathon amongst Microsoft partners in order to test an early build. I think that the SPFx is going to be excellent and I have already build a number of web parts with it. But this post isn’t really about that.

I won the hackathon with a highly configurable ‘My Documents’ style web part and received a top of the line Surface Book. Just wanted to brag about it.

That's me getting awarded a Surface Book by Dan Kogan of MSFT.
That’s me getting awarded a Surface Book by Dan Kogan of MSFT.

Paul.