Heft + SPFx < 1.22 = Runtime Errors (and the Fix) when running "serve" (heft start)

If you’ve recently converted an SPFx project to use Heft, but your SharePoint Framework version is below 1.22.x, you may hit a pair of opaque runtime errors that don’t clearly point to the real problem.

The Symptoms

You’ll see something like:

Uncaught runtime errors:

ERROR

Unknown promise rejection reason

    at handleError (https://localhost:4321/dist/...)

And sometimes (see below my guess as to when):

Uncaught runtime errors:

ERROR

Old FRE behavior is disabled

    at get._deferLoadingFeatureHostControl (...)

This looks like something fundamentally broken in your web part. In reality, the issue is a tooling/runtime mismatch.

Root Cause

When you migrate an SPFx project to use Heft, you are effectively aligning with the newer SPFx build pipeline.

However:

• Heft-based builds assume SPFx 1.22.x+

• Projects running SPFx 1.21.x or earlier are not fully compatible

• The failure manifests at runtime, not build time

This is why everything may compile successfully, but the web part fails during execution.

To make things more interesting:

If you are using:

import { ???? } from '@pnp/spfx-controls-react';

@pnp/spfx-controls-react

You may encounter additional friction after upgrading, because at the time of writing, some PnP controls have not been fully aligned with SPFx 1.22.x typings.

I am not 100% sure, but I think this caused the second issue (the Old FRE behavior is disabled error)

The Fix

Step 1 — Upgrade to SPFx 1.22.x

Upgrade your project to:

"@microsoft/sp-component-base": "1.21.1",
"@microsoft/sp-core-library": "1.21.1",
"@microsoft/sp-lodash-subset": "1.21.1",
"@microsoft/sp-office-ui-fabric-core": "1.21.1",
"@microsoft/sp-property-pane": "1.21.1",
"@microsoft/sp-webpart-base": "1.21.1",

Version:

1.22.x

Then:

Delete node modules folder, delete the package-lock.json file, and run npm install.

Rebuild and repackage.

This resolves the Heft runtime mismatch.

---

After Upgrading: PnP Controls Typing Issue

Once upgraded, you may see TypeScript errors with PnP React controls — especially around context.

Example:

<FilePicker
  context={this.props.context}
/>

You may get a typing error because the control expects a slightly different context type under 1.22.x.

Temporary Workaround

Cast the context to any:

<FilePicker
  // eslint-disable-next-line @typescript-eslint/no-explicit-any -- SPFx 1.22 temporary compatibility workaround for PnP controls
  context={this.props.context as any}
/>

Yes — this will raise a lint warning.
Yes — you are intentionally suppressing it.
Yes — it is acceptable as a temporary compatibility shim until the PnP controls fully align.

Content types missing in Site Pages library "New" dropdown, and not able to create pages

Symptoms

User goes to site pages, clicks the "new" button and only sees "link" and "folder"

Library settings show the site page content type or other content types that were added to the library.

User can still create pages if they go to an existing page and use the new button there, but once a page gets created there is no way to change its content type.

Solution

As a global 365 admin, go to the sharepoing admin site, click Settings > Pages > and then "Allow users to create new modern pages"

 Notes

This should also be a warning for admins who turn this off - it does not actually prevent users from creating modern pages - I was still able to do so using both the "new" button in a page and also using powershell.

Copying sharepoint multi user field values from one item to another in powerapps

'Target Field Name':ForAll(varSourceItem.'Source Field Name',{

                    '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",

                    Claims: Claims,

                    Department: Department,

                    DisplayName: DisplayName,

                    Email: Email,

                    JobTitle: JobTitle,

                    Picture: Picture

                })

Mass-changing powerapps controls settings

One of the most annoying powerapps restrictions is when you add a form (edit or view), all cards exist independently from each other and there is no way to "theme" them to look the same. 

So if I have an application with lots of forms and I want to have all the labels be a specific font, font size and weight, I have to do it on each label, in each form....uggghh!

The solution I came up with is:

1. Install VSCode and the powerapps extension in vscode (Power Apps Guide - Code - The new easier way to pack and unpack canvas app source code - Power Apps Guide - Blog)
2. download your app, and extract it using the extension (see link above for detailed instructions):
   pac canvas unpack --msapp .\myapp.msapp --sources .\myapp\
3. Decide on a single label that will be your master label, or a variable name that will contain your defaults. we will need the name of that label or the variable for later - lets call it XYZ for now.
4. open the app folder in vs code, and do a find and replace with the following settings:

In the find box, turn on reg ex and type:

^(\s*DataCardKey.*As label:)

this will find all lines that start with "DataCardKey" and end with "As label:".

By default these are the lines that microsoft powerapps will add to the code when adding a data card. This is the definition of the header (label) of the data card.

In the replace box, type:

$1

                    FontWeight: =XYZ.FontWeight

                    Color: =XYZ.Color

This will add to all instances of the "datacardkey?? as label:" the fontweight and color (in this example) to copy from your "master" label. Alternatively you can create app wide variables for the weight\color or other properties.

You will probably need to fix some problems that the vscode will highlight.

Next, re-pack the app:
pac canvas pack --sources .\ --msapp c:\code\myapp.msapp

Then upload it to a new canvas app (or override the existing one)

Create a canvas app, click "file">"open".

Now if you change the properties you configured on the master label, everything else will flow.

Making the workbench full width

I often am frustrated by the forced max width of the workbench - which inhibits my web part testing. To overcome this, I add the following in the componentDidMount of my web part during development phase:

$("#workbenchPageContent").attr("style","max-width:inherit");

Getting user ID by email in REACT SPFX web part

Missed me? I'm back!

Here is a small function I whipped up for React web parts that need the user id.

 /**

     * Fetches the user ID for the specified user

     * @param email the email for the user

     * @returns a promise containing the user ID in the site collection

     * example:

     * var userID = await this.getUserIDByEmail(this.props.wpContext.pageContext.user.email);

     */

    private async getUserIDByEmail(email:string):Promise<number>

    {

        var url = `${this.props.wpContext.pageContext.site.absoluteUrl}/_api/web/siteusers?$filter=Email eq '${email}'`;

        var userData:any = await  Query.GetQueryData(this.props.wpContext,url);

        return userData.value[0].Id;

    }

this refers to a class I created called Query where I put some code to help me do queries:

export default class Query {

  public static async GetQueryData(context: WebPartContext, url: string) {

    var deferred = $.Deferred();

    console.log(`running query '${url}'`);

    let _nometaOpt: ISPHttpClientOptions = {

      headers: { 'Accept': 'application/json;odata=nometadata', 'odata-version': '', 'Content-type': 'application/json;odata=verbose' }

    };

    context.spHttpClient.get(url, SPHttpClient.configurations.v1, _nometaOpt).then(

      (response: SPHttpClientResponse) => {

        if (response.status == 200) {

          console.log("got query results");

          if (response.headers.get("content-type").indexOf("atom") > -1) {

            console.log("Got xml instead of json on " + url);

            response.text().then((text:string) => {

              deferred.resolve(text);

            });

          }

          else {

            response.json().then((jsondata: JSON) => {

              deferred.resolve(jsondata);

            });

          }

        }

        else {

          console.log("error getting query results!");

          console.log(response.status);

        }

      }, (err: any) => {

        debugger;

        console.log("error getting query results!");

        console.log(err);

      });

    return deferred;

  }

}

Restricting a User Picker field to only selecting SharePoint groups

 After a lot of research, I couldn't find the answer, so I wrote one myself.
To change a person field in sharepoint that is configured to allow "users and groups" to only allow groups, you need to inject code that changes the picker settings after the page is loaded.

Code below:

$(document).ready(function(){

//wait for the initialisation of the sharepoint script 

  SP.SOD.executeFunc('sp.js', 'SP.ClientContext', function(){

//call our special function with the field's internal name

    SetGroupOnly("myfieldinternalname");

  });

});

function SetGroupOnly(fieldName)

{

//make sure there is a control for that field on the page

  if($("div[id^='"+fieldName+"_']").length>0)

  {

    //wait for the initialisation of the control to finish

    WaitForControl("div[id^='"+fieldName+"_'][id$='$ClientPeoplePicker']", function(){

//get the people picker control object

      var peoplepicker = SPClientPeoplePicker.SPClientPeoplePickerDict[$("div[id^='"+fieldName+"_'][id$='$ClientPeoplePicker']").attr("id")];

//set the type to SPGroup

      peoplepicker.PrincipalAccountType = "SPGroup";

      peoplepicker.PrincipalAccountTypeEnum = 8;

      peoplepicker.ResolvePrincipalSource = 15;

      peoplepicker.SearchPrincipalSource = 15;

    });

  }

}

function WaitForControl(controlSelector, returnFunction)

{

  if($(controlSelector).length>0)

    returnFunction();

  else

    setTimeout(function(){

      WaitForControl(controlSelector,returnFunction)},50);    

}

User is in SharePoint Group but doesn't get permissions

Found this today - a user shows up in a SharePoint group, but when you do a permission check the user doesnt have permissions to resources in sharepoint that the group has permissions to.
One explanation to this that I found is when the user was added to the group using the API (REST, JSOM, CSOM) by specifying the user's login name (domain\username). Turns out that adds the user to the group, but not the correct user....so it looks right, but it isn't. what is the correct user? you have to add the claims token "i:0#.w|" before the domain\username to properly add the user.
This off course applies to the code that adds the users. As far as I can tell you will have to remove the incorrect users, and then add them again either manually or using code.

When Cumulative doesn't mean Cumulative

 So, I just tried adding a new server to a farm, after patching it to the same level as all other servers in the farm (April 2017 CU).
Surprisingly, the SharePoint configuration wizard told me off, saying the server is missing the December 2016 CU.

Yes, that is right - the April 2017 CU does not include the CU that was released 5 months before it...Cumulative? nope!

Taxonomy field value doesnt set

We had a puzzle today, which we were sure was an issue with the document property parser in SharePoint. Every time we tried to set the value of a specific column using either our existing powershell script or an event handler that works on every other library in the system, the document would be updated with the property value, but after a second we'd refresh the page and see the value went back to null.

It was frustrating! I was sure it was because the document had an empty value in the document properties that was overriding the value from my code - despite the fact that my code is implemented with a delay to ensure it runs after the parser.

We troubleshooted several ways and couldn't find the solution...until we noticed something weird when we were looking at the content type schema - the taxonomy field was set to support multiple values! our code was specifically written for that field, which is not supposed to support multiple values. Some nasty little elf went into the column setting in the library and changed my precious from its normal settings. Setting it back and everything went to normal.

Moral of the story - since setting a taxonomy field's value in code is different if the field supports multivalue or not, make sure either your code is robust enough to handle a nasty user making a change, or tell your users to keep their hands to themselves!