While there are a few smaller updates under the hood, this major release focuses on one very important breaking change: The way the CLI authenticates with SharePoint and Microsoft 365.

If you use the CLI to automatically generate models based on your SharePoint lists, this article is for you. Here is everything you need to know about the new authentication process.

Goodbye sp-request (Username & Password)

In previous versions, the CLI used the sp-request package. This allowed you to connect to your SharePoint environment by simply typing in your username and password.

While this was very easy to use, it had some big problems:

1. Security: Sending a username and password directly is no longer recommended.

2. MFA (Multi-Factor Authentication): Username and password logins often fail if your organization uses MFA or conditional access policies. Microsoft is actively disabling basic authentication across all tenants.

To make the CLI future-proof and much more secure, username and password authentication is no longer supported in version 2.0.0.

Welcome msal-node (Modern Authentication)

To replace the old method, the CLI now uses the official Microsoft Authentication Library for Node.js (@azure/msal-node).

Instead of a user account, you now need an App Registration in Microsoft Entra ID (formerly Azure AD). This is the modern, secure way to connect to Microsoft 365.

Depending on your needs, you can now choose between two different authentication methods:

1. The Device Code Flow (Easy & Interactive)

If you only provide a Client ID to the CLI, it will use the Device Code Flow.

How it works: The CLI will show you a short code and a Microsoft login URL in your terminal. You just open the link in your browser, enter the code, and log in securely with your normal Microsoft 365 account (MFA works perfectly here!).

• Behind the scenes: This method uses Delegated Permissions and connects to the SharePoint REST API. The authentication is cached, so you don't have to log in every single time.

2. The Client Credentials Flow (Automated & Background)

If you provide both a Client ID and a Client Secret to the CLI, it will use the Client Credentials Flow.

How it works: The CLI logs in automatically in the background without any browser interaction. This is great if you don't want to be interrupted or if you are running scripts automatically.

• Behind the scenes: This method uses Application Permissions (App-Only) and connects to the Microsoft Graph API.

Important: SharePoint REST API vs. Microsoft Graph API

Because the two flows use different APIs under the hood, there is a small difference in the models that the CLI generates for you:

• When using Device Code (SharePoint REST API): The CLI gets full details about your SharePoint lists. It can read hidden fields and knows the exact types of complex fields (like Taxonomy or URL fields).

• When using Client Credentials (Graph API): The Graph API is very fast, but it does not return all field details. Hidden fields cannot be read, and complex fields (like Taxonomy) might be typed as any in your generated TypeScript model.

If you need strict type safety for complex fields, I highly recommend using the Device Code Flow (leaving the Client Secret empty).

Ready to upgrade?

You can install the new version globally via npm right now:

Bash

npm i @spfxappdev/cli -g

To learn exactly how to set up your App Registration in Azure and configure the CLI, please check out the updated documentation on the GitHub repository

Thank you for using the CLI, and happy coding!

The Investigation

I started by searching for an official API endpoint to get the footer logo URL. After scouring the internet and the official API documentation, I found that there was absolutely no information available - no articles, no forum posts, nothing.

So, I decided to take a closer look at the standard footer itself and analyze the API calls it makes. To my surprise, I found that it uses the well-known getMenuState function from the navigation API (PnPJS), but with a specific menu node key. In this case, the key is a static GUID: 13b7c916-4fea-4bb2-8994-5cf274aeb530.

The breakthrough: All data is stored in the navigation

It turns out SharePoint stores the entire footer configuration the logo, the footer name, and the navigation nodes as a “hidden” navigation menu. By querying this menu, I discovered that special items like the logo and name are identified by nodes with static GUIDs as their titles.

• Footer Logo: The node for the logo always has the title 2e456c2e-3ded-4a6c-a9ea-f7ac4c1b5100. The URL to the image is stored in its SimpleUrl property.

• Footer Name: The node for the footer's name has the title 7376cd83-67ac-4753-b156-6a7b3fa0fc1f.

• Footer Links/Nodes: The "real" navigation links are stored as children under the node with the title 3a94b35f-030b-468e-80e3-b75ee84ae0ad.

Response JSON Example

To make it clearer, here is a shortened example of the JSON response from the getMenuState API call:

{
  "@odata.context": "https://sscwebdev.sharepoint.com/sites/arano/_api/$metadata#SP.MenuState",
  //...
  "Nodes": [
    {
      //...
      "Nodes": [
        {
          //...
          "OpenInNewWindow": null,
          "SimpleUrl": "",
          "Title": "Footer Name",
          "Translations": []
        }
      ],
      "Title": "7376cd83-67ac-4753-b156-6a7b3fa0fc1f", //ID for Footer Name
    },
    {
      //...
      "OpenInNewWindow": null,
      "SimpleUrl": "/sites/site1/SiteAssets/__footerlogo__site1.png",
      "Title": "2e456c2e-3ded-4a6c-a9ea-f7ac4c1b5100", //ID for Footer Logo
      "Translations": []
    },
    {
      //...
      "Nodes": [
        {
          "AudienceIds": [],
          "CurrentLCID": 1033,
          "CustomProperties": [],
          "FriendlyUrlSegment": "",
          "IsDeleted": false,
          "IsHidden": false,
          "IsTitleForExistingLanguage": false,
          "Key": "2018",
          "Nodes": [],
          "NodeType": 0,
          "OpenInNewWindow": false,
          "SimpleUrl": "http://google.de",
          "Title": "My Footer Nav Item 1",
          "Translations": []
        }
      ],
      "NodeType": 0,
      "OpenInNewWindow": null,
      "SimpleUrl": "/sites/site1",
      "Title": "3a94b35f-030b-468e-80e3-b75ee84ae0ad", //ID for all other Nodes for Footer as "Subnodes"
      "Translations": []
    }
  ],
  "SimpleUrl": "/sites/site1",
}

PnPJS Implementation

With this knowledge, it's easy to create a function using PnPJS to fetch and parse this data. Here is a simplified example without full error handling:

//All other imports...
import { ISPFXContext, spfi, SPFI, SPFx } from '@pnp/sp';
import '@pnp/sp/webs';
import '@pnp/sp/navigation';

export default class FooterApplicationCustomizer extends BaseApplicationCustomizer<IFooterApplicationCustomizerProperties> {
    //All other Code
    public async onInit(): Promise<void> {
        await super.onInit();
        const sp: SPFI = spfi().using(SPFx(this.context as ISPFXContext));
        const footerNodes = await sp.navigation.getMenuState('13b7c916-4fea-4bb2-8994-5cf274aeb530');
        const footerLogoNode = footerNodes.Nodes[0].find(node => node.Title === '2e456c2e-3ded-4a6c-a9ea-f7ac4c1b5100');
        const footerLogoUrl = footerLogoNode ? footerLogoNode.SimpleUrl : null;
    }
}

Of course, you don't need PnPJS for this. The whole thing also works with a direct REST API call.

To do this, simply call the following endpoint, which you can also paste directly into your browser to test it:

[your-sharepoint-site]/_api/navigation/MenuState?menuNodeKey='13b7c916-4fea-4bb2-8994-5cf274aeb530'

Happy Coding ;)

The Problem: Overkill Libraries

There are a variety of drag-and-drop libraries for React. But many of them have too much extra stuff: complex animations, lots of settings and large file sizes. For simple tasks, like reordering a list of elements in an SPFx component, these libraries can be too much.

The Solution: @spfxappdev/sortable - Keep It Simple

@spfxappdev/sortable is designed to be the opposite of these feature-rich libraries. It's a minimalist React component that provides basic drag-and-drop sorting functionality without any extras. Here's what makes it stand out:

• Lightweight: Small bundle size, ensuring your application stays lean (unpacked ~62kb).

• Simple API: Easy to use and integrate into your existing projects.

• No Dependencies: Zero external dependencies, minimizing potential conflicts (except React, of course).

• Basic Functionality: Focuses on the core task of reordering elements.

Why I Built It: SPFx and Beyond

My main reason for creating @spfxappdev/sortable was my frequent need for simple sorting in SharePoint Framework (SPFx) projects. I often found myself wanting to give users the ability to customize the order of items in a list, but I didn't want to add a large and complex library to my project.

However, @spfxappdev/sortable isn't just for SPFx. It's a flexible solution for any React project where you need basic drag-and-drop sorting without the extra weight.

How to Use @spfxappdev/sortable

Using @spfxappdev/sortable is very easy. Here's a quick example:

import * as React from "react";
import {
  Sortable
} from "@spfxappdev/sortable";

interface Item {
  id: number;
  text: string;
}

const SimpleList: React.FunctionComponent = () => {
  const [items, setItems] = React.useState<Item[]>([
    { id: 1, text: "Item 1" },
    { id: 2, text: "Item 2" },
    { id: 3, text: "Item 3" },
  ]);

  const handleOnChange = (
    items: Item[],
    changedItem?: Item,
    oldIndex?: number,
    newIndex?: number
  ) => {
    // Update your state here.  This example assumes you know which list changed.
    // In a real app, you'd likely need to identify the list.

    setItems([...items]);
  };

  return (
    <div>
      <Sortable
        items={items}
        onChange={handleOnChange}
      >
        {items.map((item: Item): JSX.Element => {
          return (
            <div key={item.id} className="list-item">
              {item.text}
            </div>
          );
        })}
      </Sortable>
    </div>
  );
};

export default SimpleList;

As you can see, the API is straightforward:

• Pass your list of items to the items prop.

• Provide a onChange callback to update the order of the items.

• Render your items as children of the Sortable component.

Installation

To install @spfxappdev/sortable, simply run:

 npm install @spfxappdev/sortable

When to Use @spfxappdev/sortable

@spfxappdev/sortable is ideal for cases where:

• You need basic drag-and-drop sorting.

• You want to keep your bundle size low.

• You prefer a simple and easy-to-use API.

• You don't need fancy animations or complex features.

When to Look Elsewhere

If your project needs advanced features like:

• Complex animations.

• more complex drag and drop behaviors.

Then you may want to look for a more detailed library.

Conclusion

@spfxappdev/sortable shows the power of simplicity. It's a lightweight and easy-to-use solution for basic drag-and-drop sorting in React. If you're tired of big libraries and just want a simple way to reorder your list items, give @spfxappdev/sortable a try.

Demo

In the GitHub project repository in the “samples” folder you will find some examples that you can run locally.

Additionally you can find samples on codesandbox

As you know, you have the property this.context.pageContext in SPFx. You also know the legacyContext property in the pageContext object. The name might be scary and probably many do not use this property because of the name. But there is a lot of information right there. And whether certain features are activated or not, among other things.

However, if you want to know whether the Scheduling Feature is activated or not, you can check this as follows:

this.context.pageContext.legacyPageContext.featureInfo.SitePagesScheduling.Enabled

BTW: The featureInfo contains a lot more information about other features

Happy Coding ;)

?loadSPFX=true&debugManifestsFile=https%3A%2F%2Flocalhost%3A4321%2Ftemp%2Fmanifests.js

to the URL to test your solution. If you're working on an Application Customizer and the Solution isn't installed yet, you need to add a bit more to the URL:

?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js&customActions={"yourAppIDFrom_manifest.json":{"location":"ClientSideExtension.ApplicationCustomizer"}}

Note: You should replace yourAppIDFrom_manifest.json in the URL with your own ID.

This method usually works well. However, if you use a service class in your Extension (this.context.serviceScope.consume(...)) and begin debugging as mentioned, you will see an error message in the console.

Error: Failed to create application customizer 'ClientSideExtension.ApplicationCustomizer.YOUR_APP_ID'

and the information:

Extension failed to load for componentId "YOUR_APP_ID"

How to fix this error

My colleague asked me if I could help him with the error. We found out that the code was not loaded, not even the constructor. Initially, I suspected a problem with how the service was set up. However, even after making a new, empty service class, the error persisted. Then, I decided to add the app to the app catalog and install it. That solved the problem!

I'm not sure why this happens. It's different from web parts, where services work fine during debugging without needing to install anything.

PS: Once the Application Customizer is installed, you don't need the long URL query with the customActions parameter anymore. Otherwise, it will load twice. After installation, this is all you need:

?loadSPFX=true&debugManifestsFile=https%3A%2F%2Flocalhost%3A4321%2Ftemp%2Fmanifests.js

Happy Coding ;)

The user should be able to search/filter the list in the dropdown component. You can fulfill this requirement with a custom React component.

Just create a new react component. The Properties are inherited from IDropdownProps but with two additional properties.

onSearchValueChanged(searchValue: string): void;
searchboxProps?: Omit<ISearchBoxProps, 'onChange' | 'onClear' | 'onSearch'>;

The onSearchValueChanged property is required because you need to handle the event when a user enters something in the search field (= You want to filter the list according to the search term).

Why I exclude the onChange , onClear and onSearch for searchboxProps ?

I think all three properties should deal with the same event: the user searching for something. This is the reason why the onSearchValueChanged property is required. As a developer, you should be able to determine how the list should be filtered. In my opinion, the onChange, onClear, and onSearch properties (from the Fluent UI SearchBox Component) should trigger the event with a single event. This is the reason why I created the onSearchValueChanged property. This event is automatically triggered on onChange, onClear, and onSearch.

Use searchboxProps to set all search box properties, except onChange, onClear, and onSearch. The reason was explained earlier. These events are not needed anymore. Use onSearchValueChanged instead.

The render method

The content of the render method is really simple and short. It is enough to render the default Dropdown component of Fluent UI and pass all the properties of the component to the control (since the properties inherit from IDropdownProps). Here is the code:

public render(): React.ReactElement<ISearchableDropDownProps> {
    return (
      <Dropdown
        {...this.props}
        options={this.getOptions()}
        onRenderOption={(
          option?: ISelectableOption,
          defaultRender?: (props?: ISelectableOption) => JSX.Element | null,
        ): JSX.Element | null => {
          return this.onRenderOption(option, defaultRender);
        }}
      />
    );
  }

As you can see, I am overriding the onRenderOption method and the options property. I'll describe why I'm doing this. First, let's take a look at the getOptions method

The getOptions method

private getOptions(): IDropdownOption[] {
    const result: IDropdownOption[] = [];

    result.push({
      key: "search",
      text: "",
      itemType: SelectableOptionMenuItemType.Header,
    });

    return result.concat([...this.props.options]);
  }

I think it's self-explanatory. We add a "dummy" option with the key "search" as the option header. Then, the original options are merged.

The onRenderOption method

Now, let's take a look at what the onRenderOption looks like:

private onRenderOption(
    option?: ISelectableOption,
    defaultRender?: (props?: ISelectableOption) => JSX.Element | null,
  ): JSX.Element | null {
    if (!option) {
      return null;
    }

    if (
      option.itemType === SelectableOptionMenuItemType.Header &&
      option.key === "search"
    ) {
      return (
        <SearchBox
          {...this.props.searchboxProps}
          onChange={(
            ev?: React.ChangeEvent<HTMLInputElement>,
            newValue?: string,
          ): void => {
            if (typeof this.props.onSearchValueChanged === "function") {
              this.props.onSearchValueChanged(newValue || "");
            }
          }}
          onSearch={(newValue: string): void => {
            if (typeof this.props.onSearchValueChanged === "function") {
              this.props.onSearchValueChanged(newValue);
            }
          }}
          onClear={() => {
            if (typeof this.props.onSearchValueChanged === "function") {
              this.props.onSearchValueChanged("");
            }
          }}
        />
      );
    }

    if (typeof this.props.onRenderOption === "function") {
      return this.props.onRenderOption(option, defaultRender);
    }

    if (!defaultRender) {
      return null;
    }

    return defaultRender(option);
  }

Okay, this method is a bit longer, but not too difficult to understand. We check if the current option element (ISelectableOption) is of type "Header" and the key is "search". If so, we add the FluentUI SearchBox component and pass all searchboxProps properties to the search box. Then, we override the onChange, onSearch, and onClear methods. This allows us to trigger our own onSearchValueChanged function (see above).

Otherwise, if it is not our search option, we call the custom onRenderOption method (= Your own defined render method) if this property is defined, or execute the defaultRender method.

That's it. The component is ready for use. Here is the complete code:

import * as React from "react";
import {
  Dropdown,
  IDropdownProps,
  IDropdownOption,
  SelectableOptionMenuItemType,
  ISelectableOption,
  SearchBox,
  ISearchBoxProps,
} from "@fluentui/react";

export interface ISearchableDropDownProps extends IDropdownProps {
  onSearchValueChanged(searchValue: string): void;
  searchboxProps?: Omit<ISearchBoxProps, "onChange" | "onClear" | "onSearch">;
}

interface ISearchableDropDownState {}

export default class SearchableDropDown extends React.Component<
  ISearchableDropDownProps,
  ISearchableDropDownState
> {
  public state: ISearchableDropDownState = {};

  public static defaultProps: Partial<ISearchableDropDownProps> = {
    searchboxProps: {
      autoComplete: "false",
      autoFocus: true,
    },
  };

  public render(): React.ReactElement<ISearchableDropDownProps> {
    return (
      <Dropdown
        {...this.props}
        options={this.getOptions()}
        onRenderOption={(
          option?: ISelectableOption,
          defaultRender?: (props?: ISelectableOption) => JSX.Element | null,
        ): JSX.Element | null => {
          return this.onRenderOption(option, defaultRender);
        }}
      />
    );
  }

  private onRenderOption(
    option?: ISelectableOption,
    defaultRender?: (props?: ISelectableOption) => JSX.Element | null,
  ): JSX.Element | null {
    if (!option) {
      return null;
    }

    if (
      option.itemType === SelectableOptionMenuItemType.Header &&
      option.key === "search"
    ) {
      return (
        <SearchBox
          {...this.props.searchboxProps}
          onChange={(
            ev?: React.ChangeEvent<HTMLInputElement>,
            newValue?: string,
          ): void => {
            if (typeof this.props.onSearchValueChanged === "function") {
              this.props.onSearchValueChanged(newValue || "");
            }
          }}
          onSearch={(newValue: string): void => {
            if (typeof this.props.onSearchValueChanged === "function") {
              this.props.onSearchValueChanged(newValue);
            }
          }}
          onClear={() => {
            if (typeof this.props.onSearchValueChanged === "function") {
              this.props.onSearchValueChanged("");
            }
          }}
        />
      );
    }

    if (typeof this.props.onRenderOption === "function") {
      return this.props.onRenderOption(option, defaultRender);
    }

    if (!defaultRender) {
      return null;
    }

    return defaultRender(option);
  }

  private getOptions(): IDropdownOption[] {
    const result: IDropdownOption[] = [];

    result.push({
      key: "search",
      text: "",
      itemType: SelectableOptionMenuItemType.Header,
    });

    return result.concat([...this.props.options]);
  }
}

How to use it

You can use the component like the FluentUI Dropdown component, but with two relevant exceptions. First, you need to take care of filtering the options when a user searches for something, or set the initial values when the search is finished or something is selected. Second, you should definitely set the defaultSelectedKey(s) or selectedKey(s) property; otherwise, the "selected" element(s) will be changed when the user searches for an element.

Example

<SearchableDropDown
    defaultSelectedKey={this.state.selectedKeys}
    onChange={(ev: any, option) => {
            this.setState({
              selectedKeys: option ? option.key.toString() : "",
              filteredItems: [...initialItems],
            });
    }}
    onSearchValueChanged={(searchValue: string) => {
            const newOptions = this.onDropDownSearch(
              searchValue,
              initialItems,
            );
            this.setState({
              filteredItems: newOptions,
            });
          }}
    options={this.state.filteredItems}
/>

The onDropDownSearch method looks like this:

private onDropDownSearch(
    searchValue: string,
    initialValues: IDropdownOption[],
  ): IDropdownOption[] {
    if (isNullOrEmpty(searchValue)) {
      return [...initialValues];
    }

    //OR FIlter but whatever you want...
    const filteredOptions = [...initialValues].Where(
      (i) =>
        i.text.Contains(searchValue) &&
        (!isset(i.itemType) || i.itemType === DropdownMenuItemType.Normal),
    );

    return filteredOptions;
  }

BTW: In this example, I use my @spfxappdev/utility package to filter (Where) and to check if the search value is empty and set (isNullOrEmpty).

Sandbox / Demo

You can try out my solution in my Codesandbox demo (or here with many options/items). Feel free to copy/modify the code (maybe you can write a comment about what was changed 😊)

What do you think? How do you like it? I would be happy about feedback.

Happy coding ;)

Today I published a new version of the CLI, v1.1.2. This version comes with a new feature. It will help you to save a lot of time.

I guess almost everyone who works with SharePoint and SharePoint API has the same challenge. You need to aggregate a list and the items in it. So far so good, but sometimes the (internal) field names are, shall we say, "unfriendly". For example, if you create a new field via the UI and choose a display name like My Fancy Column, SharePoint generates the internal/static name and sets it to My_x0020_Fancy_x0020_Column

To get the value from the list item (via SharePoint REST API), you need to do something like this:

const myModel = new MyModel();
const listItem = listItemCollection[i];
myModel.myFancyColumn = listItem['My_x0020_Fancy_x0020_Column'];

And that's exactly what can be done faster and easier with the CLI in just a few seconds. Let's demonstrate it using the standard SitePages library.

#Long
spfxappdev generate model Page --weburl https://{tenant}.sharepoint.com --username "your@email.com" --password "yourPW" --list SitePages
#Short (with alias)
spfx g m Page --u https://{tenant}.sharepoint.com --user "your@email.com" --p "yourPW" --l SitePages

The generated interface is:

export interface IPage {
    name: string;
    complianceAssetId: string;
    wikiContent: string;
    title: string;
    authoringCanvasContent: any;
    bannerImageURL: UrlFieldValue;
    description: string;
    promotedState: number;
    firstPublishedDate: Date;
    pageLayoutContent: any;
    authorBylineId: number[];
    topicHeader: string;
    sitePageFlags: string[];
    callToAction: string;
    originalSourceUrl: string;
    originalSourceSiteID: string;
    originalSourceWebID: string;
    originalSourceListID: string;
    originalSourceItemID: string;
    id: number;
    contentType: string;
    created: Date;
    createdById: number;
    modified: Date;
    modifiedById: number;
    copySource: string;
    checkedOutToId: number;
    checkInCommentId: number;
    type: string;
    fileSize: string;
    itemChildCountId: number;
    folderChildCountId: number;
    commentCountId: number;
    likeCountId: number;
    sensitivityId: number;
    edit: string;
    sourceVersionConvertedDocumentId: number;
    sourceNameConvertedDocumentId: number;
}

The generated class looks like this:

import { IPage } from './';
import { mapper } from '@spfxappdev/mapper';
import { UrlFieldValue } from './';
export class Page implements IPage {
    @mapper({ nameOrPath: 'FileLeafRef',  })
    public name: string;

    @mapper({ nameOrPath: 'ComplianceAssetId', toClassOnly: true })
    public complianceAssetId: string;

    @mapper({ nameOrPath: 'WikiField',  })
    public wikiContent: string;

    @mapper({ nameOrPath: 'Title',  })
    public title: string;

    @mapper({ nameOrPath: 'CanvasContent1',  })
    public authoringCanvasContent: any;

    @mapper({ nameOrPath: 'BannerImageUrl', type: UrlFieldValue,  })
    public bannerImageURL: UrlFieldValue;

    @mapper({ nameOrPath: 'Description', toClassOnly: true })
    public description: string;

    @mapper({ nameOrPath: 'PromotedState', toClassOnly: true })
    public promotedState: number;

    @mapper({ nameOrPath: 'FirstPublishedDate', type: Date, toClassOnly: true })
    public firstPublishedDate: Date;

    @mapper({ nameOrPath: 'LayoutWebpartsContent',  })
    public pageLayoutContent: any;

    @mapper({ nameOrPath: 'OData__AuthorBylineId.results',  })
    public authorBylineId: number[];

    @mapper({ nameOrPath: 'OData__TopicHeader',  })
    public topicHeader: string;

    @mapper({ nameOrPath: 'OData__SPSitePageFlags.results', toClassOnly: true })
    public sitePageFlags: string[];

    @mapper({ nameOrPath: 'OData__SPCallToAction',  })
    public callToAction: string;

    @mapper({ nameOrPath: 'OData__OriginalSourceUrl', toClassOnly: true })
    public originalSourceUrl: string;

    @mapper({ nameOrPath: 'OData__OriginalSourceSiteId', toClassOnly: true })
    public originalSourceSiteID: string;

    @mapper({ nameOrPath: 'OData__OriginalSourceWebId', toClassOnly: true })
    public originalSourceWebID: string;

    @mapper({ nameOrPath: 'OData__OriginalSourceListId', toClassOnly: true })
    public originalSourceListID: string;

    @mapper({ nameOrPath: 'OData__OriginalSourceItemId', toClassOnly: true })
    public originalSourceItemID: string;

    @mapper({ nameOrPath: 'ID', toClassOnly: true })
    public id: number;

    @mapper({ nameOrPath: 'ContentType',  })
    public contentType: string;

    @mapper({ nameOrPath: 'Created', type: Date, toClassOnly: true })
    public created: Date;

    @mapper({ nameOrPath: 'AuthorId', toClassOnly: true })
    public createdById: number;

    @mapper({ nameOrPath: 'Modified', type: Date, toClassOnly: true })
    public modified: Date;

    @mapper({ nameOrPath: 'EditorId', toClassOnly: true })
    public modifiedById: number;

    @mapper({ nameOrPath: 'OData__CopySource', toClassOnly: true })
    public copySource: string;

    @mapper({ nameOrPath: 'CheckoutUserId', toClassOnly: true })
    public checkedOutToId: number;

    @mapper({ nameOrPath: 'OData__CheckinCommentId', toClassOnly: true })
    public checkInCommentId: number;

    @mapper({ nameOrPath: 'DocIcon', toClassOnly: true })
    public type: string;

    @mapper({ nameOrPath: 'FileSizeDisplay', toClassOnly: true })
    public fileSize: string;

    @mapper({ nameOrPath: 'ItemChildCountId', toClassOnly: true })
    public itemChildCountId: number;

    @mapper({ nameOrPath: 'FolderChildCountId', toClassOnly: true })
    public folderChildCountId: number;

    @mapper({ nameOrPath: 'OData__CommentCountId', toClassOnly: true })
    public commentCountId: number;

    @mapper({ nameOrPath: 'OData__LikeCountId', toClassOnly: true })
    public likeCountId: number;

    @mapper({ nameOrPath: 'OData__DisplayNameId', toClassOnly: true })
    public sensitivityId: number;

    @mapper({ nameOrPath: 'Edit', toClassOnly: true })
    public edit: string;

    @mapper({ nameOrPath: 'ParentVersionStringId', toClassOnly: true })
    public sourceVersionConvertedDocumentId: number;

    @mapper({ nameOrPath: 'ParentLeafNameId', toClassOnly: true })
    public sourceNameConvertedDocumentId: number;    
}

As you can see, the CLI generates the class using the @mapper decorator. This decorator is a part of my npm package. It is developed to map a model to a SharePoint API result and vice versa. Another point you may have noticed is that the internal names are stored in the nameOrPath property, but the model property is more the general name specification in camelCase.

But how you can "convert" the API Result to your model and back to the SP List Model? It is very easy:

import { toClass, toPlain  } from '@spfxappdev/mapper';
import { Page } from '@src/models';

class MyService {

    public async getPages(): Promise<IPage[]> {
        //const pageCollection = await ...Your API call
        const pages: Page[] = toClass(Page, pageCollection);
        return pages;
    }

    public updatePage(page: IPage): Promise<void> {
        const spData = toPlain(page);

        //YOUR REST API CALL TO UPDATE THE PAGE
    }
}

The toPlain method ignores properties labeled as toClassOnly: true because they are read-only fields, like Editor/Author, and can't be updated.

That is great, isn't it?

By the way, you don't have to pass all the values like --weburl, --username and --password every time. You can set the values once via the config set command and then these values will be used (the password is encrypted).

Also new in this version: You can now create local configuration files. So you can have different configurations per project.

What do you think? How do you like it? I would be happy about feedback.

Happy coding ;)

In this blog post, I will explain how to use semantic versioning for your project and how to understand the version ranges of your dependencies.

Semantic versioning

Semantic versioning is a convention for assigning meaningful version numbers to software projects. It follows the format of MAJOR.MINOR.PATCH, where:

• MAJOR is incremented when you make incompatible API changes

• MINOR is incremented when you add functionality in a backward-compatible manner

• PATCH is incremented when you make backward-compatible bug fixes

For example, if you have a project with the version 1.2.3 and you add a new feature without breaking any existing functionality, you can increase the MINOR part and make it 1.3.0. If you fix a bug without changing the API, you can increase the PATCH part and make it 1.3.1. If you change the API in a way that breaks existing code, you can increase the MAJOR part and make it 2.0.0.

Semantic versioning helps you communicate the changes in your project and avoid compatibility issues with other projects that depend on yours.

Version ranges

When you specify the versions of your dependencies in the package.json file, you can use different symbols to indicate the range of acceptable versions. These symbols are:

• ~ (tilde): This means that you accept any patch updates within the same minor version. For example, ~1.4.0 means that you accept any version from 1.4.0 to 1.4.x, but not 1.5.x or higher.

• ^ (caret): This means that you accept any minor or patch updates within the same major version. For example, ^1.4.0 means that you accept any version from 1.4.0 to 1.x.x, but not 2.x.x or higher.

• * (asterisk): This means that you accept any version of the dependency. This is not recommended as it can introduce breaking changes or bugs without your control.

• > (greater than), < (less than), >= (greater than or equal to), <= (less than or equal to): These symbols allow you to specify a range of versions using inequality operators. For example, >=1.4.0 <2.0.0 means that you accept any version from 1.4.0 to 1.x.x, but not 2.x.x or higher.

• - (hyphen): This allows you to specify a range of versions using a dash. For example, 1.4.0 - 2.0.0 means that you accept any version from 1.4.0 to 2.0.0 inclusive.

• || (double pipe): This allows you to combine multiple ranges using an OR operator. For example, ^1.4.0 || ^2.0.0 means that you accept any version from 1.x.x or 2.x.x.

When you run npm install, npm will look at the version ranges of your dependencies and install the latest compatible version available.

Why use version ranges?

Using version ranges allows you to benefit from bug fixes and new features without having to update your package.json file every time a new version of a dependency is released.

However, there are also some risks involved with using version ranges:

• You may introduce breaking changes or bugs if a dependency updates its API in an incompatible way within the same major version.

• You may miss important updates if a dependency releases a new major version with significant improvements or security fixes.

• You may have inconsistent results if different developers or environments install different versions of the same dependency.

To mitigate these risks, you can use tools like npm audit or npm outdated to check for vulnerabilities or outdated dependencies in your project.

You can also use tools like npm shrinkwrap or npm lockfile.

I hope this article helped you to better understand versioning in npm

Happy Coding ;)

UPDATE: I introduced the CLI in the PnP community call. You can see the CLI in action here.

You are probably asking yourself, why create your own CLI at all? To be honest, the idea came up very spontaneously. I have many customers and for them, I create SPFx projects. The projects are (if not otherwise specified) always built and configured by me in the same way. But some configurations I can't (or don't want to) remember. So I "copy" the gulp and tsconfig configurations from other projects. I don't want to say that it takes a lot of time, probably a maximum of 15 minutes per project. But it sucks to copy and then paste everything etc. Besides, with time it became more and more configurations. Also, with such a CLI, I could provide a corporate standard. So that all my colleagues have the same procedure. And that's when the idea was born. A CLI should do this job for me. In addition, I have never created a CLI and wanted to expand my knowledge about it.

The first thing I had to figure out was how to create a CLI. Some tools can help with this like commander or yargs. I chose yargs for no particular reason. But what should the CLI be able to do?

As mentioned before, I wanted to map my typical configurations. Those who follow my blog know that I often give tips and tricks around SPFx development. That's why the CLI is based on the following blog articles:

• My personal tips how to configure a SPFx project after creation

• Using pnpm in SPFx projects

• Package SPFx solution with one command and automatically increase the version

• SPFx Azure DevOps Pipeline: Increment version, push to repository and publish package

I started with a single command, the init command. This configured everything from my last post.

1. A new folder @spfxappdev is created in the root directory of the project

2. The gulpfile.js file is modified: Aliases are registered, and the bump-version task is defined and the possibility to build your solution in such a way that a warning will not cause the build process to fail.

3. tsconfig.json is changed: Path aliases and baseUrl are set.

4. fast-serve/webpack.extend.js is changed (if available): Aliases are registered

5. The package.json file is modified: The publish and publish:nowarn commands are defined

After that I had the idea to install npm packages with the command. Mostly you use the same packages like @pnp/sp, then they should be installed when you call the init command. Of course it should be possible to disable it. And you should be able to configure the packages "globally". But how do you do that? After a little research, I found the package configstore.

And there was created another command config with "subcommands" to handle the configuration.

Because I don't use npm by now but pnpm, this had to be included as well. So I added the possibility to set the package manager, also using the config command.

And because I don't want to preset my settings, everybody should have the possibility to overwrite my templates. Therefore I have also created the possibility to specify own templates, which should be used when generating the ESLint and TSConfig files.

And then I had the idea that it should be possible to create a new project via the CLI. Nothing else is done than calling the yo @micrsoft/sharepoint command. Only that the configured package manager is passed automatically. In case of pnpm the following commands are also executed

pnpm config set auto-install-peers true --location project
pnpm config set shamefully-hoist true --location project

Another benefit is that you no longer have to type the long command yo @micrsoft/sharepoint. My CLI also has an alias, so you could for example enter the following command to create a new project

#Long form
spfxappdev new 
#Short form
spfx n

I don't want to go into detail now and explain every single command and what it is for. After all, that's why I wrote the documentation. For example, you can also create models or services that are automatically exported to the index.ts.

To keep it short, if you want to start with my CLI. Install it once globally:

npm i @spfxappdev/cli -g

Once installed, you can invoke CLI commands directly from your OS command line through the spfxappdev executable. If you want to start directly with a new project and the default configurations, then enter the following commands

#create a new SPFx Project
spfx new
#Initialize the project (alias, bump-version, publish command)
spfx init
#Create custom ESLint and TSConfig rules
spfx rules

That's it. Your project is created and configured. For more ways to use my CLI, you should read the documentation. I would be happy about the usage. I am looking forward to your feedback. I also like to hear suggestions for new features.

PS: I'm not done with the CLI yet. There will be more features to come. But currently, it is in a status that I can publish :)

Happy coding ;)

I will describe what I personally do after I create a new project. Some steps may not be relevant for you because you prefer a different way of working or structure your project differently. But maybe there's one or two things you didn't know yet and think it's good.

NOTE: In the meantime, I have developed a CLI that automates the settings mentioned here and more for you. Read more

SPFx fast serve

I have often mentioned that I like the npm package spfx-fast-serve developed by Sergei Sergeev. If you don't know it, you must use it! So the first step I do after creating the project is to run the spfx-fast-serve command in my terminal. This is of course only possible if you have installed the package globally before. After running the command, the tool prompts you to run the npm install command again. Since I switched to pnpm, of course, I have to run pnpm install

Configure (path) Alias

Most use relative paths to refer to files from the solution. Here are a few examples:

import HelloWorldWebPartComponent from './components/HelloWorldWebPartComponent';
import { MyComponent } from '../../components/MyComponent';

Custom aliases allow you to create (mostly) shorter and more intuitive paths for your imports. This is especially beneficial in larger projects where multiple levels of folder structures can lead to unwieldy (relative) paths. But it is also helpful if you want to reuse the modules later because then you don't have to work with the relative paths anymore. Here is the same example as above, but with the alias:

import HelloWorldWebPartComponent from ' @webparts/helloworld/components/HelloWorldWebPartComponent';
import { MyComponent } from '@components/MyComponent';

Extending tsconfig.json with baseUrl and custom Alias

The tsconfig.json file is the configuration file for TypeScript projects and provides various options to control the behavior of the TypeScript compiler. By extending this file in your SPFx solution, you can better customize the TypeScript compilation process to suit your project structure and needs.

1. Adding baseUrl

The baseUrl property in tsconfig.json allows you to set a base directory for module resolution. This means you can define a central starting point for your imports, reducing the need for long relative paths.

For example, by including a baseUrl property pointing to your project's src directory, you establish a foundation for cleaner, more intuitive imports. But I personally point to '.'. Here is an example of how the file tsconfig.json looks like after the change:

"compilerOptions": {
  "baseUrl": ".",
  // Other options...
}

2. Defining Aliases

To create a custom alias, add the paths property under compilerOptions in your tsconfig.json. This property maps aliases to their corresponding paths.

I always create an alias for the src folder (that's why my baseUrl points to '.' and not 'src'), the webparts folder and the components folder. But of course, you can also create your own alias. This is how the tsconfig.json looks like after the change:

{
  "extends": "./node_modules/@microsoft/rush-stack-compiler-4.5/includes/tsconfig-web.json",
  "compilerOptions": {
    // Other options...
    "paths": {
      "@src/*": ["src/*"],
      "@components/*": ["src/components/*"],
      "@webparts/*": ["src/webparts/*"]
    },
    "baseUrl": "."
  },
  "include": [
    "src/**/*.ts",
    "src/**/*.tsx"
  ]
}

Registering custom aliases in Gulp

After defining aliases in your tsconfig.json, you must ensure they work during the build process. This involves syncing the aliases with the build output.

In your gulpfile.js, before the build.initialize(require('gulp')); code part, add this:

build.configureWebpack.mergeConfig({
    additionalConfiguration: (generatedConfiguration: any) => {
      if (!generatedConfiguration.resolve.alias) {
        generatedConfiguration.resolve.alias = {};
      }  

      // webparts folder
      generatedConfiguration.resolve.alias['@webparts'] = path.resolve(
        __dirname,
        'lib/webparts'
      );  

      // components folder
      generatedConfiguration.resolve.alias['@components'] = path.resolve(
        __dirname,
        'lib/components'
      );

      //root src folder
      generatedConfiguration.resolve.alias['@src'] = path.resolve(
        __dirname,
        'lib'
      );  

      return generatedConfiguration;
    }
});

Make sure that you have added the path package to the beginning of your gulpfile.js

const path = require('path');

NOTE: In gulpfile, you should use the lib folder instead of src.

Registering custom aliases in spfx-fast-serve

After running the command spfx-fast-serve in your terminal (described above), the command added a new folder in the root of your project, called fast-serve, containing a file called webpack.extend.js. Again, we need to register the alias so webpack can resolve it.

There should be an (empty) variable webpackConfig in the file:

const webpackConfig = {
}

Now you have to extend this and register your alias:

const path = require('path');
const webpackConfig = {
  /* CUSTOM ALIAS START */
  resolve: {
      alias: {
        "@webparts": path.resolve(__dirname, "..", "src/webparts"),
        "@components": path.resolve(__dirname, "..", "src/components"),
        "@src": path.resolve(__dirname, "..", "src"),
      }
  },
  /* CUSTOM ALIAS END */
}

NOTE: In webpack.extend.js you should use the src path again. And because the file is in a folder, you need to add a '..' after __dirname when calling the path.resolve method. And again, do not forget to import the path package!

That's it, now you can use your defined alias instead of relative paths!

Create Gulp task to increase the (package) version

If you want to have a command to increment the SPFx solution version (config/package-solution.json) and the package.json version, then you should define a custom gulp task like I do. And even more, if you want to build the solution, increase the version and package the solution with one command, then you should read my post on how to do that.

Optional steps

I know the following steps aren't relevant to everyone or may not even appeal, but these are the ones I always do!

Disable CSS class name warnings

I often use CSS class names that do not conform to the Microsoft schema and are not camlCase. An example would be spfxappdev-grid.

When I define this, I get a warning

Warning - [sass] The local CSS class 'spfxappdev-grid' is not camelCase and will not be type-safe.

To remove this warning, you can suppress it in gulpfile.js. An SPFx project even suppresses such a warning for Microsoft's own CSS class by default. You can find it in the gulpfile.js

build.addSuppression(`Warning - [sass] The local CSS class 'ms-Grid' is not camelCase and will not be type-safe.`);

Of course, I could now add a new suppression by entering the following

build.addSuppression(`Warning - [sass] The local CSS class 'spfxappdev-grid' is not camelCase and will not be type-safe.`);

But I won't. Because I have more than just this one class. To suppress all these messages you can use RegEx:

build.addSuppression(/Warning - \[sass\] The local CSS class/gi);

That's it!

Change ESLint Rules / TypeScript rules

Since SPFx v.1.15 was released, Microsoft switched from TSLint to ESLint. Actually a good decision, but some rules annoy me personally. Especially if you use spfx-fast-serve and you are still developing the modules. Sometimes you just want to test something fast and define variables that are not used (yet). Or you comment out a code and the method is now "empty". Then errors are output and often the spfx-fast-serve process is stopped => you have to start it again after fixing.

For this reason, I change the rules before starting development. To change them, open your .eslintrc.js and set your own values. For example, I change these rules to 0 (0 = '0ff', 1 = 'warning', 2 = 'error'):

'@typescript-eslint/no-explicit-any': 0,
'@typescript-eslint/no-floating-promises': 0,
'@typescript-eslint/no-unused-vars': [
          0,
          {
            vars: 'all',
            // Unused function arguments often indicate a mistake in JavaScript code.  However in TypeScript code,
            // the compiler catches most of those mistakes, and unused arguments are fairly common for type signatures
            // that are overriding a base class method or implementing an interface.
            args: 'none',
          },
]

And then I also change the tsconfig.json. I add these compilerOptions:

"compilerOptions": {
    // Other options...
    "noImplicitAny": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
}

By the way, here is a good article if you want to learn more about ESLint with SPFx.

I don't have to do this every time, thanks to my CLI

Since I have done these above steps every time, for every project, I wanted to simplify it a bit. So I developed my own command line interface (CLI) that does just that (Read more about my CLI).

This is my typical folder structure

It has less to do with the topic of the article, but maybe someone is interested in what my folder structure looks like, which I (almost always) create. Of course not immediately, but only when I need it.

src
|- models
     |- interfaces
|- services
|- components
|- webparts
     |- components
|- ...

The components folder directly in the src folder is only for components I use in further SPFx modules (e.g. if I have more than one webpart or extension).

That's it

I hope you enjoyed the article and got some helpful tips. I would also be happy about feedback. Gladly also with your tips :)

Happy coding :)

In the new version, it should be possible to store as many usernames, passwords and notes as you want. I finally got around to adding these features. I decided to make it dynamic, in a similar "look and feel" as in SharePoint Standard, when you want to place a new webpart. It appears this "+" symbol when you hover with the mouse.

And then you can add a new module. There are modules for username, password and also notes. Once modules are placed, you can sort or remove them.

The web part now looks like this (in edit mode):

I have also made a few design adjustments/optimizations. Also, for safety, the master password must be entered twice. And I have updated the solution to SPFx 1.16.1

In the "backend", the logic has changed a bit because of the modules. But I made sure that you can update from version 1.0.0 to the new version 1.1.0 without any problems. Without data loss but with the same functionality as in the new version. Even with the changes, the values are still encrypted.

I hope you like my new webpart. You can download it here

I have always used the "normal" way via npm and never dealt with yarn or pnpm before. When I read up on the different package managers, it was immediately clear I should go for pnpm. It is (almost ever) faster and the file size and also the number of files are smaller.

After some research on the Internet, I found two very good articles by Joel Rodrigues and Andrew Connell, both Microsoft MVPs. Unfortunately, I ran into a few problems when I tried it out. This may be due to SPFx (I use SPFx 1.16.1) or because both articles are from 2018. That is why I decided to write this article. It also contains a tip that each of you can use. Let me surprise you.

Because I reinstalled my PC a few days ago, I had to set everything up again. For this reason, I reinstalled yo, gulp and @microsoft/generator-sharepoint but directly with pnpm. So I took the command from the Microsoft article and replaced npm with pnpm.

pnpm install gulp-cli yo @microsoft/generator-sharepoint --global --shamefully-hoist

However, this is not necessary if you have already installed everything via npm, because gulp and yo can be used globally.

Install pnpm

Of course, before you can use pnpm, you must first install it. I used the PowerShell command is described on the installation page.

 iwr https://get.pnpm.io/install.ps1 -useb | iex

But if you prefer npm or another method, just have a look at the official installation guide.

Note: Please check the compatibility of pnpm with your installed node version

Create a new SPFx Project with pnpm

If you want to create a new project you can use the well-known yo @microsoft/sharepoint command but you have to add the argument --package-manager pnpm.

yo @microsoft/sharepoint --package-manager pnpm

Now the standard build process is done and after that all needed npm packages are installed but with pnpm. The installation of the packages was fast, wasn't it?

I was really impressed by how fast and easy it was. So I wanted to test the standard webpart. But gulp serve threw errors. The package @microsoft/sp-component-base could not be found. Also in the SCSS file the reference to Fluent UI (@import '~@fluentui/react/dist/sass/References.scss';) could not be found.

After some research I found out that I should install all packages with the additional argument --shamefully-hoist.

To get a "clean" installation, I deleted the node_modules folder (here is an article of mine describing how to do it faster). Additionally, I deleted the file pnpm-lock.yaml (the equivalent to package-lock.json from npm). Then I executed the command

pnpm install --shamefully-hoist

Now also much more files came within the node_modules folder and also a gulp serve could be executed without errors.

You will probably wonder if you have to delete the folder or run a pnpm install --shamefully-hoist every time you want to create a new project. This would be an option, but not a very good one. A better one is to set this option in the .npmrc file. There are two possibilities.

Global .npmrc

To set the Global option, i.e. a rule that should apply to all projects, you can enter this command:

pnpm config set shamefully-hoist true

But: the .npmrc file is used by both pnpm and npm. So if you want to have custom settings ONLY for pnpm, then this should not be set globally (admittedly this setting does not exist for npm, so it could be set globally)

Locale .npmrc

Before you run yo @microsoft/sharepoint --package-manager pnpm, run this command in the project directory:

pnpm config set shamefully-hoist true --location project

Then it will apply only to the current project/folder. The disadvantage here, however, is that this step must not be forgotten. It must be important that it is executed before the yo @microsoft/sharepoint... command.

Optional: Only allow pnpm usage

When you use pnpm on a project, you do not want others to accidentally run npm install or yarn. To prevent developers from using other package managers, you can modify the package.json as follows:

    "scripts": {
        "preinstall": "npx only-allow pnpm"
        //other package.json scripts
    }
//other package.json settings

npm and pnpm compared

I have created two different projects, both are webpart projects with React and the same name. Only one with npm and the other with pnpm.

Summary

1. If you have chosen a

   1. locale "strategy" of the .npmrc file, then before creating a project you have to execute this command pnpm config set shamefully-hoist true --location project

   2. global "strategy" of the .npmrc file, then you don't need to do anything (as long as you run it once)

2. Create a new project as follows: yo @microsoft/sharepoint --package-manager pnpm

3. Optional: Change the package.json file to prevent other developers from using other package managers

Bonus

As promised, here is a bonus. Now I will show you how to make it even easier and more automated. The commands are very long and if you have chosen a locale "strategy" of the .npmrc file, then you must always remember to run the other commands first. Maybe you already know the way to define aliases via the registry (regedit) entries or via a cmd file and include (this cmd file) it in the PATH environment variable. But here I want to show something different. And that is about PowerShell aliases and profiles.

Open a new PowerShell window as administrator and run

notepad $profile.AllUsersAllHosts

If a message appears that no profile exists yet, create one. Otherwise, use your existing profile and edit the script file that opens. Now paste this code:

function spfxWithPnpm() {
    pnpm config set auto-install-peers true --location project
    pnpm config set shamefully-hoist true --location project
    yo @microsoft/sharepoint --package-manager pnpm
}

function spfxWithNpm() {
    yo @microsoft/sharepoint
}

set-alias -name spfxNpm -value spfxWithNpm -Scope Global
set-alias -name spfx -value spfxWithPnpm -Scope Global
set-alias -name pn -value pnpm -Scope Global

There are two PowerShell functions. One for the case that a project should still be created with npm. And the other one with pnpm. You could now simply run the spfxWithPnpm command from any PowerShell terminal and it would apply the (local "strategy")(#heading-local-npmrc) of the .npmrc file and create the project with pnpm. Or you could write spfxWithNpm to build it with npm. But to make it even shorter, PowerShell aliases are defined for the functions (yes, you can also just rename the functions, then you don't need the aliases anymore. Or you can handle the complete logic in one function and work with parameters). Finally, an alias is created for pnpm itself, so that you can write pn instead of pnpm (you can of course use whatever you like).

By the way: I have included auto-install-peers in the spfxWithPnpm function. This is an example if you want to make this setting only for pnpm but not for npm. As described before, both package managers use this file. But unlike shamefully-hoist, auto-install-peers is also available for npm. If you choose a global strategy for auto-install-peers, then it affects both npm and pnpm.

The great thing is, such a thing exists. And even better, it can be used by everyone by default starting from Windows 10. It's called Clipboard History. You have to enable this feature once. To do that, you just press the key combination Win (Logo) + V. You will be prompted to activate it:

If you do not see this screen, then you have already activated it!

By the way: You can check/change the setting or view advanced settings at any time via Settings => System => Clipboard => Clipboard history.

Now you can copy your item as usual with Ctrl + C and then display the history with Win (Logo) + V and paste it from there.

The history stores up to 25 last copied items and is automatically cleared after a restart of the computer. You can also pin certain items there, which will then still be listed after the reboot. Just click on the three dots "..." and select "Pin".

That's it. I use it a lot and it really helps me a lot. I hope for you too.

Happy pasting ;)

My idea is a kind of "favorites" list for SharePoint, so to speak. But why not use the favorites function of the browser? Quite simply, a URL that has been marked as a favorite is a static URL. So you can create a URL to the site contents of Site A and one for Site B. But not to Site contents of the current site collection you are on. And that was the idea. An extension that reads the current URL of the tab/window and makes the URL "dynamic". In the extension, the URL {weburl}/_layouts/15/viewlsts.aspx is replaced by the current web URL. If you are on https://tenantname.sharepoint.com/sites/siteA/SitePages/MyPage.aspx, the placeholder {weburl} is replaced by https://tenantname.sharepoint.com/sites/siteA. In this way {weburl}/_layouts/15/viewlsts.aspx becomes https://tenantname.sharepoint.com/sites/siteA/_layouts/15/viewlsts.aspx. The extension should have the following features:

• First: it should be simple and fast to implement (at least for now, the next versions can be extended). I don't have any experience with extensions yet, so it should be rather simple.

• Reading the current Tab/Windows URL

• If it is not a .sharepoint.com domain, the extension should not be usable and a hint text should be displayed

• No SharePoint API calls should be made to read out the URLs or to get the current user. The URL should only be "built up" using the browser URL of the current tab. This is helpful for performance reasons, but also for time and data protection reasons. An extension that makes an API call in the tab context, for example, is checked more strictly and longer by the Google team.

• Due to the aforementioned requirement, the links are always displayed and it is not checked whether the user has the authorization to call up this link.

• The extension should not store SharePoint data or forward it to third parties.

• It comes with some "quick links" that I find helpful. These cannot be changed, but they can be de- and activated. And the label can be changed.

• You can store your URLs, which are then also displayed and dynamically "replaced".

• There should be the placeholders {webappurl}, {weburl}, and {pageurl}.

• Only links that have been "enabled" by the user shall be displayed.

• The placeholder {pageurl} is replaced by the current (SharePoint) page URL. If you are not on a page, the links are not displayed.

• For me as a SharePoint developer and all other SharePoint developers, some URLs are of course also very useful for SPFx development. Therefore, in addition to the "normal" loadSPFx=true URL parameters (with which you can test the SPFx WebParts on the current page), there is also the option of loading an SPFx Application Customizer. For this purpose, the App Id is requested (prompt dialog) as soon as you click on the URL.

• It should be available for Chrome and all browsers that use the Chrome Extension Web Store.

Result

This is how my extension looks like:

PopUp

Configuration

SPFx App Debug

Download

Feel free to download my extension. I am happy about your feedback. You can install the extension on all Chromium-based browsers (Edge Chromuim, Google Chrome, Brave etc.). You can download it directly via the link or by searching for "SharePoint Quicklinks" in the Extension Store.

You can also find the source code for this extension in my GitHub repository

The idea is quite simple

When pushing to main/master branch, the Azure DevOps pipeline should automatically check out the branch, increment the version, build the package, check the changes back into the repository and (optionally) create a Git tag with the version number to make it clearer. You can turn off tagging or version incrementing in the pipeline. In addition, you can use the commit message to determine which part of the version (major, minor or patch) should be updated.

Here we go

Before you start with the pipeline and the .yaml file, you have to configure something. In the project settings under Repository => {NameOfRepository} => Security => USER: {NameOfRepository} Build Service. This user must be given the permissions Read, Contribute, Create tag, Create branch and Contribute to pull requests.

The yaml file

NOTE: This post and the yaml file were updated on January 25, 2024.

I won't show you how to create a pipeline but will go into the individual steps in the yaml file. If that doesn't interest you, you can jump straight to the final file and use it.

Step 1: Checkout

- checkout: self
  clean: true
  persistCredentials: true

This step determines how the pipeline should check out the source code.

Step 2: Check if gitconfig exists

Sometimes, the pipeline might fail at step 3 if the .gitconfig file already exists. So, in this step, we check if it's there. I've only made it show whether the file exists or not. You can change the script to delete the file or create a variable to use as a "condition" in step 3.

- powershell: |
   $exists = Test-Path -Path $HOME/.gitconfig
   WRITE-HOST ".gitconfig exist:" $exists
  workingDirectory: $(System.DefaultWorkingDirectory)
  displayName: Check whether gitconfig exists

Step 3: Set Git user

- script: |
   git config --global user.email devops@spfx-app.dev & git config --global user.name "spfx-app.dev".
  workingDirectory: $(System.DefaultWorkingDirectory)

This sets the user to be displayed at (code) checkin/push. The user does not have to actually exist. It will only be displayed in Azure DevOps as specified.

Step 4: PowerShell to set the output variables

As mentioned at the beginning, the version should only be incremented if it is desired (pipeline variable CI_BUMP_VERSION is set to TRUE). In addition, the commit message Build.SourceVersionMessage can be used to determine which part of the version (major, minor, or patch) should be incremented. By default, the patch version is always incremented.

- powershell: |
   $commitMsg = "$(Build.SourceVersionMessage)"
   Write-Host $commitMsg
   Write-Host "Version bump is ENABLED"

   $bumpVersionArgs = "--no-patch"
   Write-Host "##vso[task.setvariable variable=BUMP_MAJOR_VERSION;]$false"
   Write-Host "##vso[task.setvariable variable=BUMP_MINOR_VERSION;]$false"
   Write-Host "##vso[task.setvariable variable=BUMP_PATCH_VERSION;]$false"
   if($commitMsg -match "(major):.*") {
      Write-Host "Bump Major Version"
      Write-Host "##vso[task.setvariable variable=BUMP_MAJOR_VERSION;]$true"
      $bumpVersionArgs = "--major"
    }
    elseif($commitMsg -match "(minor):.*") {
      Write-Host "Bump Minor Version"
      Write-Host "##vso[task.setvariable variable=BUMP_MINOR_VERSION;]$true"
      $bumpVersionArgs = "--minor"
    }
    else {
      Write-Host "Bump Patch Version"
      Write-Host "##vso[task.setvariable variable=BUMP_PATCH_VERSION;]$true"
      $bumpVersionArgs = "--patch"
    }

    Write-Host "##vso[task.setvariable variable=BUMP_VERSION_ARGS;]$bumpVersionArgs"
  displayName: Get the commit message
  workingDirectory: $(System.DefaultWorkingDirectory)
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')

If the commit message contains a minor: the minor version is incremented. If the commit message contains a major: the major version is incremented. It is not necessary to specify patch: as it will increment the patch version by default, but this message would increment the patch version. Depending on which version part is updated, the argument for the later gulp bump command is stored in the variable BUMP_VERSION_ARGS to be passed in step 10.

Note: for a pull request, the "Title" column of the form in the UI corresponds to the variable Build.SourceVersionMessage.

Step 5: Use Node.js

- task: NodeTool@0
  displayName: 'Use Node 16.x'
  inputs:
    versionSpec: 16.x
    checkLatest: true

I think it is clear what this step does. Node version 16.x will be installed.

Note: Of course you have to adapt the version of Node to your SPFx version. A list of supported Node versions can be found here

Step 6: install pnpm (OPTIONAL)

This step is optional, but if you use pnpm instead of npm, you'll need to install pnpm first.

- task: Npm@1
  displayName: 'npm install -g pnpm'
  inputs:
    workingDir: ' $(Build.Repository.LocalPath)'
    command: 'custom'
    customCommand: 'install -g pnpm'
    verbose: true
  enabled: false

If you use pnpm, please remember to enable this step.

Step 7: npm install

- task: CmdLine@2
  displayName: 'npm install'
  inputs:
    script: 'npm i'
    workingDirectory: ' $(Build.Repository.LocalPath)'
  enabled: true

All npm packages will now be installed.

Step 8: gulp clean

- task: gulp@0
  displayName: 'gulp clean'
  inputs:
    targets: clean

The gulp task gulp clean is executed.

Step 9: gulp build (OPTIONAL)

This step is not necessary, but if you'd like, you can enable it and run the gulp build --ship command.

- task: gulp@0
  displayName: 'gulp build --ship'
  inputs:
    targets: build
    arguments: '--ship'
  enabled: false

Step 10 gulp bump-version

Now the task I described in the last blog post is used to increment the version. Again, only if the pipeline variable CI_BUMP_VERSION has been set to TRUE.

- task: gulp@0
  displayName: 'gulp bump-version'
  inputs:
    targets: 'bump-version'
    arguments: $(BUMP_VERSION_ARGS)
  continueOnError: true
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')
  enabled: true

The stored value from the variable BUMP_VERSION_ARGS from step 3 is passed as an argument (--major, --minor or --patch).

Step 11: gulp bundle --ship

The gulp task bump-version is normally executed automatically before the gulp bundle --ship task (see my blog post). But as you can tell the pipeline whether the version should be incremented or not, I had to split this task and pass the additional argument --no-ship to the gulp bundle --ship so that the bump-version task is not executed again.

- task: gulp@0
  displayName: 'gulp bundle --ship --no-patch'
  inputs:
    targets: bundle
    arguments: '--ship --no-patch'
  continueOnError: true
  enabled: true

Step 12: gulp package-solution --ship

I think this step is self-explanatory. The solution is packed.

- task: gulp@0
  displayName: 'gulp package-solution --ship'
  inputs:
    targets: 'package-solution'
    arguments: '--ship'
  enabled: true

Step 13: Read updated version from package.json

If the version was updated, it must of course be read again (for the later Git tag and also the commit message). I did this with a PowerShell script.

- powershell: |
   $newVersion = (Get-content ./package.json| out-string | ConvertFrom-Json).version
   Write-Host "##vso[task.setvariable variable=NEW_VERSION;]$newVersion"
   Write-Host $newVersion
  displayName: Get Version from package.json and set in variable
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')

The package.json file is read and the version number is stored in the variable NEW_VERSION.

Step 14: push back to Repository

Now the version is restored to the repository if the version has been updated.

- script: |
   echo $(NEW_VERSION)
   git add .
   git commit -m "[skip ci] Version updated to $(NEW_VERSION)"
   git push origin HEAD:$(Build.SourceBranch)
  displayName: Push changes to source branch
  workingDirectory: $(System.DefaultWorkingDirectory)
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')
  enabled: true

All changes are checked in with the message [skip ci] version updated to $(NEW_VERSION). The [skip ci] is very important. In case you have configured an automatic execution of the pipeline on the (main/master) branch, it would execute the pipeline again (continuous loop). This can be prevented with this text in the commit message (see: https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#skipping-ci-for-individual-commits).

Step 15: Create Git tag

I thought it was helpful that a Git tag is created at the same time as the version update and after the check in. The name of the tag is then the version number. This is only done if the variables CI_BUMP_VERSION and CI_CREATE_GIT_TAG are both set to TRUE.

- script: |
   git tag $(NEW_VERSION) HEAD
   git push origin --tags
  displayName: Create Tag for last commit version
  workingDirectory: $(System.DefaultWorkingDirectory)
  condition: and(eq(variables['CI_BUMP_VERSION'], 'TRUE'), eq(variables['CI_CREATE_GIT_TAG'], 'TRUE'))
  enabled: true

Step 16: Copy package file(s)

Now the .sppkg files are copied into the temporary drop folder.

- task: CopyFiles@2
  displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)/drop'
  inputs:
    Contents: '**/*.sppkg'
    TargetFolder: '$(Build.ArtifactStagingDirectory)/drop'
  enabled: true

Step 17: Publish Artifacts

And finally, the artifacts have to be published so that the .sppkg files can be downloaded.

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  enabled: true

That was it (almost)

The complete file

Here is the complete file:

# SPFx Build Pipeline
# Author: seryoga@spfx-app.dev
# Version: 1.0
# Steps:
#   Step 1: checkout the branch
#   Step 2: Check if gitconfig exists
#   Step 3: Set git user
#   Step 4: Check commit message and determine version bump option
#   Step 5: Use Node Version 16.x
#   Step 6: OPTIONAL (Disbaled): install pnpm (for pnpm projects only)
#   Step 7: Execute "(p)npm Install"-Command
#   Step 8: Execute "gulp clean"-Command
#   Step 9: (Disabled): Execute "gulp build --ship"-Command (not mandatory, you can disable this command when you want by adding to the task `enabled: false` after the `input`-section) 
#   Step 10: Execute "gulp bump-version"-Command
#   Step 11: Execute "gulp bundle --ship --no-patch"-Command
#   Step 12: Execute "gulp package-solution --ship"-Command
#   Step 13: Read (new) version from package.json
#   Step 14: Push the changes back to repository
#   Step 15: Create Git Tag with the new version
#   Step 16: Copy Files to: $(Build.ArtifactStagingDirectory)/drop
#   Step 17: Publish Artifacts
trigger:
- development
pool:
  name: Azure Pipelines
  vmImage: 'ubuntu-latest'
steps:
- checkout: self
  clean: true
  persistCredentials: true

- powershell: |
   $exists = Test-Path -Path $HOME/.gitconfig
   WRITE-HOST ".gitconfig exist:" $exists
  workingDirectory: $(System.DefaultWorkingDirectory)
  displayName: Check whether gitconfig exists

- script: |
   git config --global user.email devops@spfx-app.dev & git config --global user.name "spfx-app.dev"
  workingDirectory: $(System.DefaultWorkingDirectory)

- powershell: |
   $commitMsg = "$(Build.SourceVersionMessage)"
   Write-Host $commitMsg
   Write-Host "Version bump is ENABLED"

   $bumpVersionArgs = "--no-patch"
   Write-Host "##vso[task.setvariable variable=BUMP_MAJOR_VERSION;]$false"
   Write-Host "##vso[task.setvariable variable=BUMP_MINOR_VERSION;]$false"
   Write-Host "##vso[task.setvariable variable=BUMP_PATCH_VERSION;]$false"
   if($commitMsg -match "(major):.*") {
      Write-Host "Bump Major Version"
      Write-Host "##vso[task.setvariable variable=BUMP_MAJOR_VERSION;]$true"
      $bumpVersionArgs = "--major"
    }
    elseif($commitMsg -match "(minor):.*") {
      Write-Host "Bump Minor Version"
      Write-Host "##vso[task.setvariable variable=BUMP_MINOR_VERSION;]$true"
      $bumpVersionArgs = "--minor"
    }
    else {
      Write-Host "Bump Patch Version"
      Write-Host "##vso[task.setvariable variable=BUMP_PATCH_VERSION;]$true"
      $bumpVersionArgs = "--patch"
    }

    Write-Host "##vso[task.setvariable variable=BUMP_VERSION_ARGS;]$bumpVersionArgs"
  displayName: Get the commit message
  workingDirectory: $(System.DefaultWorkingDirectory)
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')

- task: NodeTool@0
  displayName: 'Use Node 16.x'
  inputs:
    versionSpec: 16.x
    checkLatest: true
  enabled: true

- task: Npm@1
  displayName: 'npm install -g pnpm'
  inputs:
    workingDir: ' $(Build.Repository.LocalPath)'
    command: 'custom'
    customCommand: 'install -g pnpm'
    verbose: true
  enabled: false

- task: CmdLine@2
  displayName: 'npm install'
  inputs:
    script: 'npm i'
    workingDirectory: ' $(Build.Repository.LocalPath)'
  enabled: true

- task: gulp@0
  displayName: 'gulp clean'
  inputs:
    targets: clean
  enabled: true

- task: gulp@0
  displayName: 'gulp build --ship'
  inputs:
    targets: build
    arguments: '--ship'
  enabled: false

- task: gulp@0
  displayName: 'gulp bump-version'
  inputs:
    targets: 'bump-version'
    arguments: $(BUMP_VERSION_ARGS)
  continueOnError: true
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')
  enabled: true

- task: gulp@0
  displayName: 'gulp bundle --ship --no-patch'
  inputs:
    targets: bundle
    arguments: '--ship --no-patch'
  continueOnError: true
  enabled: true

- task: gulp@0
  displayName: 'gulp package-solution --ship'
  inputs:
    targets: 'package-solution'
    arguments: '--ship'
  enabled: true

- powershell: |
   $newVersion = (Get-content ./package.json| out-string | ConvertFrom-Json).version
   Write-Host "##vso[task.setvariable variable=NEW_VERSION;]$newVersion"
   Write-Host $newVersion
  displayName: Get Version from package.json and set in variable
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')

- script: |
   echo $(NEW_VERSION)
   git add .
   git commit -m "[skip ci] Version updated to $(NEW_VERSION)"
   git push origin HEAD:$(Build.SourceBranch)
  displayName: Push changes to source branch
  workingDirectory: $(System.DefaultWorkingDirectory)
  condition: eq(variables['CI_BUMP_VERSION'], 'TRUE')
  enabled: true

- script: |
   git tag $(NEW_VERSION) HEAD
   git push origin --tags
  displayName: Create Tag for last commit version
  workingDirectory: $(System.DefaultWorkingDirectory)
  condition: and(eq(variables['CI_BUMP_VERSION'], 'TRUE'), eq(variables['CI_CREATE_GIT_TAG'], 'TRUE'))
  enabled: true

- task: CopyFiles@2
  displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)/drop'
  inputs:
    Contents: '**/*.sppkg'
    TargetFolder: '$(Build.ArtifactStagingDirectory)/drop'
  enabled: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  enabled: true

Creating the variables

Before you save the pipeline, you must create variables. To do this, click on the "Variables" button at the top right of the editor and then on "+". Enter the variable name CI_BUMP_VERSION and the value TRUE. If you want to change these values when running manually, you have to select "Let users override this value when running this pipeline". Save the variable and do the same with the variable CI_CREATE_GIT_TAG. Save the settings and then save the pipeline. Now it is ready to run.

Result

When the pipeline has gone through, it now looks like this:

And the tags were created:

Again, as a hint: Through the commit message you can define whether major, minor or patch version should be counted up.

Happy Coding ;-)

Most people (and I have to admit that I am one of them) almost never incremented this number. At least the packages did not have to be "updated" manually and received all changes immediately. You also have to remember to update the version number. It is, of course, clear that this is not the purpose of versioning. But recently, Microsoft has published an important update, which obliges to update the version number. Because if you do not updates the version, the solution changes will not be visible. So you have two options:

1. Uninstall solution, delete solution from the Recycle Bin, delete solution from the 2nd Stage Recycle Bin and then reinstall.

2. Update the version number and then perform an "update" for the app.

I think it is clear which is faster/easier. But the problem is that you must not forget to update the version. I came across the "automatic version increment" on a blog a few years ago, which uses a gulp task. But - as described above - I didn't see the point in incrementing the version because the other thing is easier. Upload solution - done. No update, no waiting. It is simple and fast. With the Microsoft Update, such a task makes sense, of course. So I went looking for this script again and came across another - but still useful - blog article by Tom Daly. I found his code quite good and wanted to adapt it to my needs.

For my SPFx solutions that I publish on GitHub, I include the version number in the web parts. This has become established for many WebParts. For this purpose, I usually use the PnP Property Pane Controls and the control PropertyPaneWebPartInformation. To display the version number, you can access the Web Part context object this.context.manifest.version. The problem is that this is not the version number from package-solutions.json, but the one from package.json. This is needed for npm. But npm, like many others, uses the Semantic Versioning. This version has 3 digits. So 1.0.0 (Major.Minor.Patch).

My goal was to automatically update both, the package-solution.json and the package.json and to keep them "in sync". The revision number of the package-solution.json is completely ignored. The version number should always be incremented automatically when the gulp bundle command is executed with the parameter --ship. Alternatively, you can just update the version with the command gulp bump-version. You can specify which part of the versioning should be updated with the additional parameters --major, --minor or --patch. Whereas --patch is the default. If you don't want to update the version in the gulp bundle --ship command, you can just type gulp bundle --ship --no-patch and then nothing will be done with the version.

To use my script, you need to add the following lines to the top of gulpfile.js (if not already there):

const gulp = require('gulp'); 
const gutil = require('gulp-util'); 
const fs = require('fs');

Then replace the last line build.initialize(require('gulp')); with build.initialize(gulp);. And before this line, insert the following code:

var getJson = function (file) {
  return JSON.parse(fs.readFileSync(file, 'utf8'));
};

let bumpVersionSubTask = build.subTask('bump-version-subtask', function(gulp, buildOptions, done) {

  const currentCommand = buildOptions.args._[0];

  const skipFunc = gulp.src('./config/package-solution.json').pipe(gutil.noop());

  if(typeof currentCommand != "string") {
    gutil.log("The current command is undefined, skip version bump");
    return skipFunc;
  }

  const commandName = currentCommand.toLocaleLowerCase();

  if(commandName != "bundle" && commandName != "bump-version") {
    gutil.log("The current command is not 'bundle' or 'bump-version', skip version bump");
    return skipFunc;
  }

  const bumpVersion = commandName == "bump-version" || buildOptions.args["ship"] === true;

  if(!bumpVersion) {
      gutil.log("The current command is not 'bump-version' or the --ship argument was not specified, skip version bump");
      return skipFunc;
  }

  const a = buildOptions.args;

  const skipMajorVersion = typeof a["major"] == "undefined" || a["major"] === false;
  const skipMinorVersion = !skipMajorVersion || typeof a["minor"] == "undefined" || a["minor"] === false;
  const skipPatchVersion = !skipMajorVersion || !skipMinorVersion || a["patch"] === false;

  if(skipMajorVersion && skipMinorVersion && skipPatchVersion) {
    gutil.log("skip version bump, because all specified arguments (major, minor, patch) are set to 'false'")
    return skipFunc;
  }

  const pkgSolutionJson = getJson('./config/package-solution.json');
  const currentVersionNumber = String(pkgSolutionJson.solution.version);
  let nextVersionNumber = currentVersionNumber.slice();
  let nextVersionSplitted = nextVersionNumber.split('.');
  gutil.log('Current version: ' + currentVersionNumber);

  if(!skipMajorVersion) {
    nextVersionSplitted[0] = parseInt(nextVersionSplitted[0]) + 1;
    nextVersionSplitted[1] = 0;
    nextVersionSplitted[2] = 0;
    nextVersionSplitted[3] = 0;
  }

  if(!skipMinorVersion) {
    nextVersionSplitted[1] = parseInt(nextVersionSplitted[1]) + 1;
    nextVersionSplitted[2] = 0;
    nextVersionSplitted[3] = 0;
  }

  if(!skipPatchVersion) {
    nextVersionSplitted[2] = parseInt(nextVersionSplitted[2]) + 1;
    nextVersionSplitted[3] = 0;
  }

  nextVersionNumber = nextVersionSplitted.join(".");

  gutil.log('New version: ', nextVersionNumber);

  pkgSolutionJson.solution.version = nextVersionNumber;
  fs.writeFile('./config/package-solution.json', JSON.stringify(pkgSolutionJson, null, 4), () => {});

  const packageJson = getJson('./package.json');
  packageJson.version = nextVersionNumber.split('.').splice(0, 3).join(".");
  fs.writeFile('./package.json', JSON.stringify(packageJson, null, 4), () => {});

  return gulp.src('./config/package-solution.json')
  .pipe(gulp.dest('./config'));
});

let bumpVersionTask = build.task('bump-version', bumpVersionSubTask);
build.rig.addPreBuildTask(bumpVersionTask);

The complete "gulpfile.js" looks like this:

'use strict';

const gulp = require('gulp');
const build = require('@microsoft/sp-build-web');
const gutil = require('gulp-util');
const fs = require('fs');

build.addSuppression(`Warning - [sass] The local CSS class 'ms-Grid' is not camelCase and will not be type-safe.`);

var getTasks = build.rig.getTasks;
build.rig.getTasks = function () {
  var result = getTasks.call(build.rig);

  result.set('serve', result.get('serve-deprecated'));

  return result;
};

var getJson = function (file) {
  return JSON.parse(fs.readFileSync(file, 'utf8'));
};

let bumpVersionSubTask = build.subTask('bump-version-subtask', function(gulp, buildOptions, done) {

  const currentCommand = buildOptions.args._[0];

  const skipFunc = gulp.src('./config/package-solution.json').pipe(gutil.noop());

  if(typeof currentCommand != "string") {
    gutil.log("The current command is undefined, skip version bump");
    return skipFunc;
  }

  const commandName = currentCommand.toLocaleLowerCase();

  if(commandName != "bundle" && commandName != "bump-version") {
    gutil.log("The current command is not 'bundle' or 'bump-version', skip version bump");
    return skipFunc;
  }

  const bumpVersion = commandName == "bump-version" || buildOptions.args["ship"] === true;

  if(!bumpVersion) {
      gutil.log("The current command is not 'bump-version' or the --ship argument was not specified, skip version bump");
      return skipFunc;
  }

  const a = buildOptions.args;

  const skipMajorVersion = typeof a["major"] == "undefined" || a["major"] === false;
  const skipMinorVersion = !skipMajorVersion || typeof a["minor"] == "undefined" || a["minor"] === false;
  const skipPatchVersion = !skipMajorVersion || !skipMinorVersion || a["patch"] === false;

  if(skipMajorVersion && skipMinorVersion && skipPatchVersion) {
    gutil.log("skip version bump, because all specified arguments (major, minor, patch) are set to 'false'")
    return skipFunc;
  }

  const pkgSolutionJson = getJson('./config/package-solution.json');
  const currentVersionNumber = String(pkgSolutionJson.solution.version);
  let nextVersionNumber = currentVersionNumber.slice();
  let nextVersionSplitted = nextVersionNumber.split('.');
  gutil.log('Current version: ' + currentVersionNumber);

 if(!skipMajorVersion) {
    nextVersionSplitted[0] = parseInt(nextVersionSplitted[0]) + 1;
    nextVersionSplitted[1] = 0;
    nextVersionSplitted[2] = 0;
    nextVersionSplitted[3] = 0;
  }

  if(!skipMinorVersion) {
    nextVersionSplitted[1] = parseInt(nextVersionSplitted[1]) + 1;
    nextVersionSplitted[2] = 0;
    nextVersionSplitted[3] = 0;
  }

  if(!skipPatchVersion) {
    nextVersionSplitted[2] = parseInt(nextVersionSplitted[2]) + 1;
    nextVersionSplitted[3] = 0;
  }

  nextVersionNumber = nextVersionSplitted.join(".");

  gutil.log('New version: ', nextVersionNumber);

  pkgSolutionJson.solution.version = nextVersionNumber;
  fs.writeFile('./config/package-solution.json', JSON.stringify(pkgSolutionJson, null, 4), () => {});

  const packageJson = getJson('./package.json');
  packageJson.version = nextVersionNumber.split('.').splice(0, 3).join(".");
  fs.writeFile('./package.json', JSON.stringify(packageJson, null, 4), () => {});

  return gulp.src('./config/package-solution.json')
  .pipe(gulp.dest('./config'));
});

let bumpVersionTask = build.task('bump-version', bumpVersionSubTask);
build.rig.addPreBuildTask(bumpVersionTask);

build.initialize(gulp);

Now you can use the task gulp bundle --ship or gulp bump-version to automatically bump up the version.

One command for complete release including version update

To publish the package, you normally have to execute the following commands:

gulp clean

gulp build

gulp bundle --ship

gulp package-solution --ship

Of course, you can also use the shorthand notation gulp clean; gulp build; gulp bundle --ship; gulp package-solution --ship. But this also takes a long time. That's why I show you here how you can do everything at once with one command. Including version updates. I have thought of the command publish for this. You can simply use the npm scripts for this. Open the package.json file and enter the following under the scripts property:

"publish": "gulp clean && gulp build && gulp bundle --ship",
"postpublish": "gulp package-solution --ship"

Now you can just run npm run publish in the terminal and you have everything in one command. Even the version is incremented because of our previously described gulp task.

By the way, if you don't want the version to be incremented, just run the command like this npm run publish -- --no-patch. If the major version is to be updated, then just use npm run publish -- --major. For minor then npm run publish -- --minor.

I hope it has helped you and that you - like me - have saved some time.

Happy coding ;-)

I have seen sensitive data such as user name and password in plain text in many intranets. Why should one worry about such things on an intranet? After all, it can only be seen by the staff, can't it?

But something like that is still not secure if it is in plain text. Let's say I'm in a team meeting (which is even being recorded) and I am sharing my screen and I visit the page that contains the login data. And the data could be "stolen". This is just one example of many.

I then had the idea of developing a webpart where you can set a master password to encrypt the user name and password. And only after entering this master password, the entered data should be decrypted and displayed in plain text. A typical password vault such as Dashlane, KeyPass or Bitwarden. Only somewhat simplified and only for one user name and password. To be able to enter further information/notes, I have added a text field (Rich text editor), which is also encrypted. This could be used, for example, to store several user data.

The webpart should contain the following features:

• If you have not yet set a master password (webpart newly added). The vault does not have to be unlocked. The master password has to be set first.

• If a master password has already been set, the vault must first be unlocked to view or adjust the data.

• The data must also be stored encrypted in SharePoint. This means that the data must not be visible in SharePoint maintenance mode.

• The encrypted values can only be decrypted with the master password.

• The user name and password can be copied to the clipboard with one click.

• The password is in a password field and is therefore not displayed unless it is actively displayed by the user.

• The vault can be closed manually or will be closed automatically after 5 minutes after the page has been refreshed.

Now it was time for the implementation. For encryption and decryption, I decided to use the JavaScript library crypto-js, which I already know and which is loved by many. The master password is hashed (and salted) with SHA256. The other data is logically not hashed, but encrypted and decrypted with the Advanced Encryption Standard (AES). A combination of a key defined by me + master password is used as the key value for encryption and decryption.

Result

Display Mode

If the vault is closed, the user has to enter the master password (does not matter if in display or edit mode)

After the user has entered the correct master password, he/she can view the stored data. The password is not visible in plain text unless the "show password" icon has been clicked on

Edit Mode

In page edit mode, it is possible to update the master password or change the data.

And yes, if you lose the master password, all data cannot be recovered. Not even by the administrator.

Maintenance Mode

And to prove that the data is encrypted and is not displayed in maintenance mode, here is an example of the data stored in the webpart.

Source and Download

You can find the source code in my GitHub repository. If you want to test/use the web part you can find the SharePoint package file here.

I would appreciate your feedback. You can leave a comment here in the post or use my GitHub repository for it.

Update March 13, 2023

I have updated the solution and added new features. See here

The only possibility is to define a label and whether it should be displayed or not. And, of course, the "position" (address) itself.

In my off time, after general working hours and on weekends, I took the time to provide a SPFx solution that has/can do everything I think you need. It took me about 24h of development time spread over many days. With my web part, you can place as many markers as you want. You can set if a tooltip is shown when hovering the mouse over the marker and also what kind of text should be shown in this tooltip. You can adjust the pin color and the icon displayed in it or omit it completely. You can also define what should happen when you click on the marker. Should a panel with further information open or maybe a dialog with freely definable text? Maybe nothing should happen or you should be redirected to a page (URL). There would also be the possibility to display the entered URL embedded in a dialog (iFrame). If there are many markers, you can decide if they should be clustered. Then you can see circles with the number of markers when you zoom out further. You don't like the tile layer (map "look and feel")? No problem, then change that too. Do you want to define categories, so that you don't have to "design" every marker anew and to show a legend for it? This is also no problem. It is also easier to edit categories afterwards. This is because all markers that have been assigned to a category are also updated after editing. It goes so far that you can even make the map static. This means that the user can neither zoom nor switch to another (map) point (dragging disabled). The web part can also be integrated into Microsoft Teams as a tab. Here you can see an example of my web part:

There are many use cases for my solution:

• Display all locations of the company
• Marking all customers on a map
• Plan the next team event and show the meeting points, including the information about it
• A static page header as a "banner" for the location page
• etc.

Curious? Then visit the product website and learn how to download, install and use it.

I would appreciate your feedback. You can leave a comment here in the post or use my GitHub repository for it.

The SPFx version 1.4.1 (for SP 2019 on-premises) already supported Node v8 LTS and also npm v4.

Yesterday (February 17, 2022) SPFx was released in version 1.14. This Version requires at least Node v12 LTS. You can find a listing of compatible versions here.

That's no problem, you might think. Then the latest version is installed or updated to the latest version. Well, it's not quite that simple. What if you still have "old" projects. Projects that you have to continue to maintain and that were developed for SP2019 or even SP2016, for example. Because installing two different Node versions at the same time is not possible on one computer. Sure, you can use a VM. But then you have many VMs that also consume CPU/RAM and especially disk space unnecessarily. And you have to set up each of them.

Setup the docker Container

My next project (not SharePoint) is supposed to use Docker. Docker is of course a term I know, after all, everyone talks about it. But I had no experience with it. To not start with this project without knowledge about Docker, I watched a super good video on Youtube (in German) by Golo Roden two days ago (BTW: You can find the same article in German here). He explained it insanely well and I now probably have more than basic knowledge about Docker. After that I thought, actually, you could create something like that for SPFx. Then you wouldn't have to set up the environment at all (saves time) and you can use different versions at the same time. Before I create my own Dockerfile, I checked if there is already a Docker image for SPFx. There is one. I wanted to try that out right away. By the way, I'm not going to go into how you set up/install Docker or what it is, how it works, or how to use it. That's not relevant to the article either. There is also no Docker knowledge required.

Two days ago SPFx 1.14 was not officially released. Therefore I downloaded the image for SPFx 1.13. The documentation for the Docker image is quite good, however, I stumbled upon a couple of obstacles. Already in the first step!

in Docker Settings > Shared Drives verify that the drive where you create your projects is shared

This setting does not exist for me! This has several reasons. The "Shared Drive" has not been available under Docker Desktop for quite some time. Actually, it should be under Docker Settings > Resources > File Sharing.

Yes, I know, I need to update my Docker Desktop 😜

But even this setting is not to be found in my case. It must be said that I have a Windows 10 operating system and use WSL 2 (Windows Subsystem for Linux).

Under WSL 2, you don't need a file share because everything runs on the local machine instead of on a Hyper-V backend.

After I figured that out, I wanted to get started on the next steps. So I created a folder. Then entered the command there as described in the documentation:

docker run -it --rm --name spfx-helloworld -v ${PWD}:/usr/app/spfx -p 4321:4321 -p 35729:35729 m365pnp/spfx

Let me briefly explain the commands:

docker run creates a new container

-it stands for interactive, i.e. you stay "in the container" after creating it. This is mostly a terminal/bash window

--rm means that after the container is terminated, it will be deleted as well.

--name is the name of the container

-v is the volume mapping. The current local path (${PWD}) is mapped to the container path usr/app/spfx.

-p stands for port. This maps the local port 4321 to the container port 4321. And the port 35729 with the container port 35729.

And finally the name of the image is specified ==> m365pnp/spfx.

The container is created and a shell opens. This shell is the shell of the container. That's why you have to specify all your yo, npm, gulp and other commands there and not on the local computer.

That means, after the yo @microsoft/sharepoint command, type all your npm, gulp etc. commands. Only when you are 100% done (e.g. package published, testing finished etc.), enter exit. After that, the container is finished and will be deleted immediately because of the --rm parameter. But don't worry, not the project. It is on your local computer. If you want to work with the project later, you simply have to create the container again (in the project directory) as described above.

Theoretically, you could now serve the project with gulp serve. But this will not work the first time. This is also described in the Docker image documentation. Because you first need to edit the serve.json file, which is located in the config folder. For this, you have to set the hostname to 0.0.0.0.

{
  "$schema": "https://developer.microsoft.com/json-schemas/core-build/serve.schema.json",
  "port": 4321,
  "hostname": "0.0.0.0",
  "https": true,
  "initialPage": "https://yourtenant.sharepoint.com/_layouts/workbench.aspx"
}

Because I used - as described at the beginning - the SPFx version 1.13, according to the instructions, I also had to edit a JavaScript file in line 393, which should be located here:

node_modules\@microsoft\spfx-heft-plugins\lib\plugins\webpackConfigurationPlugin\WebpackConfigurationGenerator.js

But this is not correct either. Because this file is located under:

node_modules\@microsoft\sp-build-web\node_modules\@microsoft\spfx-heft-plugins\lib\plugins\webpackConfigurationPlugin\WebpackConfigurationGenerator.js

You don't have to do this step anymore in the new SPFx version 1.14. Microsoft itself now checks whether you are in a container or not (by ipAddress-Property in serve.json). If you are using a different version, please check the Docker image documentation to see if there is anything else you need to be aware of. By the way, version 1.14 also fixed my reported bug with the Fullmask Permission Check 😊

Now you could run gulp serve and call the SharePoint workbench. https://{tenant}.sharepoint.com/_layouts/15/workbench.aspx

But you will find that your component is not present/listed. This issue is not listed at all in the Docker Image documentation. The reason is that the certificate is not trusted. It doesn't matter if you already ran gulp trust-dev-cert on your local environment or if you did it in the container. To display the SPFx component you have to call the URL https://localhost:4321 (on the local environment). After that, you have to trust the certificate.

Your component should now be listed in the workbench (or wherever).

SPFx Fast Serve in Docker Container

I am a very big fan of the spfx-fast-serve Package (if you don't know it, you must use it!). That's why I tried to use spfx-fast-serve in this container too. There was a GitHub issue related to Docker Container for this package, which was already solved, but the "workaround" was not acceptable to me like this. Therefore I tried to solve the problem in a different way. Since yesterday there is also a solution for this. Sergei Sergeev, the author of the package, will now officially include my solution in his readme.

To use spfx-fast-serve in your container, you just have to open fast-serve/webpack.extend.js and adjust the constant webpackConfig:

const webpackConfig = {
  devServer: {
    host: '0.0.0.0',
    publicPath: 'https://0.0.0.0:4321/dist/',
    sockHost: 'localhost',
    watchOptions: {
      aggregateTimeout: 500, // delay before reloading
      poll: 1000 // enable polling since fsevents are not supported in docker
    }
  },
  output: {
    publicPath: 'https://0.0.0.0:4321/dist/'
  }
}

Now the npm run serve command also works in the container.

Custom Docker image. 70% Smaller and with spfx-fast-serve

The official Docker image is already very good and helpful. What I didn't like was the image size. It is 1.22 GB and I didn't want to install the spfx-fast-serve package all the time. Therefore I thought about creating my own image. I learned in the Youtube Video that the Linux Alpine operating system is much smaller. Because it is delivered without certain packages, which the other Linux distributions use. This means that with the SPFx Docker Image, the Linux distribution takes up so much space or better said, the used Node image uses this Linux version. But you can also use Node in the Alpine version. So I copied the original Dockerfile and made it "Alpine"-Ready. Because the commands for Alpine are different from those of Ubuntu, Debian etc. I translated it, so to speak.

The result is the following Dockerfile with the default integration of the package spfx-fast-serve:

FROM node:14.19.0-alpine3.15

EXPOSE 5432 4321 35729

ENV NPM_CONFIG_PREFIX=/usr/app/.npm-global \
  PATH=$PATH:/usr/app/.npm-global/bin

VOLUME /usr/app/spfx
WORKDIR /usr/app/spfx

RUN apk add sudo && \
    apk --no-cache add shadow && \
    echo '%wheel ALL=(ALL) ALL' > /etc/sudoers.d/wheel && \
    adduser --home "$(pwd)" --disabled-password --ingroup wheel --shell /bin/ash spfx && \
    usermod -aG wheel spfx && \
    chown -R spfx:wheel /usr/app

USER spfx

RUN npm i -g gulp@4 yo @microsoft/generator-sharepoint@1.13.1 spfx-fast-serve

CMD /bin/ash

If you compare the image sizes, my image is 70% smaller, and only 400MB.

In this container you have to do the same steps I described above. After creating the solution you can run spfx-fast-serve once (it doesn't need to be installed anymore, that was done in the Docker image) and then npm i and you can use npm run serve.

That's it. Happy Coding ;)