Build, Run and Deploy your first SharePoint Framework Web Part

Build, Run and Deploy your first SharePoint Framework Web Part

Why SharePoint Framework?

Earlier to SharePoint Framework, client-side development to SharePoint sites was achieved by embedding JavaScript, HTML, and CSS code in either Content Editor Web Part, Script editor, SharePoint master page or the Page layout.
It used to function just fine but was riddled with problems. Difficult maintainability, cumbersome source code integration, testing and continuous deployment to name a few. It was more like client-side web parts of yesteryears – functional but antiquated.
SharePoint Framework (SPFx) allows us to implement client-side development with a modern development approach. SPFx makes packaging and deploying customization to SharePoint sites a breeze.
One can write code on real IDE – like VS Code, Visual Studio etc.
We can use Team Foundation Server (now called Azure Dev Ops) for source code integration, unit testing, and probably continuous deployment. Instead of TFS/Azure Dev Ops one can also use Git, Bitbucket or GitHub.
In today’s post we will learn it first hand by developing and deploying an example SharePoint Framework web part.

Setup development environment

In order to setup your development environment – follow my previous post, where I talked about various tool chains that are required for SharePoint Framework development. For additional assistance refer to this article to setup your development environment. You may not have access to Office365 at tenant level to create a development site. In that case, you can ask your tenant administrator to enable App Catalog and also enable Developer site collection feature on an existing O365 site collection. If you don’t have Office 365 at all then you can get one by joining Office 365 Developer Program

Building the Web Part

Microsoft has a nice article which explains about building an example SharePoint Framework (SP Fx) web part.
In summary follow below steps:

  • Create a directory
  • Create the web part project using yeoman generator. Use below information to answer questions prompted

Running the Web Part

Now we need to preview our webpart, for that we need to rely on gulp, it is task runner which handles build process such as:

  • Bundle and minify JavaScript and CSS files.
  • Run tools to call the bundling and minification tasks before each build.
  • Compile SASS files to CSS.
  • Compile TypeScript files to JavaScript.

Type gulp serve in terminal window.

Ensure you are at the root of web part solution directory. This will create a local NodeJS Server. Once we run gulp serve a browser will be opened with our local workbench, this is where we will edit our page and add the webpart for testing. (Note: at this point, you can also use SharePoint workbench to run and test your web part. Type in your SharePoint root URL and append /_layouts/workbench.aspx. It will connect to your local NodeJS server and now you can access SharePoint resources as well. It is handy when your code is interacting with real SharePoint resources like lists, library, user field etc.)

Deploying the Web Part

Deploying the web part can be tricky sometimes if you don’t have access or knowledge about Office 365 or Azure CDN. In this case, we will try to keep things simple by deploying resources to SharePoint library. Follow this article to deploy your web part to a SharePoint page. Note that in this case web part resources like CSS, script and html files are still being served from local computer. Your web part will not render if gulp serve is not running or if someone else is visiting that page from their computer. To deploy packaged files to SharePoint library

  • Go to package-solution.json inside your solution directory – Ensure that includeclientsiteasset is set to false
{
  "$schema": "https://developer.microsoft.com/json-schemas/spfx-build/package-solution.schema.json",
  "solution": {
    "name": "hello-webpart-sp-library-deployment-client-side-solution",
    "id": "7da7bc99-0470-4839-b11b-1abdb027c170",
    "version": "1.0.0.0",
    "includeClientSideAssets": false,
    "skipFeatureDeployment": true
  },
  "paths": {
    "zippedPackage": "solution/hello-webpart-sp-library-deployment.sppkg"
  }
}
  • Now go to write-manifests.json inside your solution directory – Update CDN Path to a SP library. I would recommend creating a new SharePoint library for hosting packaged files. Create a folder for each web part for better maintainability.
{
  "$schema": "https://developer.microsoft.com/json-schemas/spfx-build/write-manifests.schema.json",
  "cdnBasePath": "https://yoursharepointsite/yoursharepointlibrary/foldername"
}
  • After running
    gulp bundle --ship
    and
    gulp package-solution --ship
    Upload files from temp–>deploy folder to SharePoint library folder (in same path as updated in write-manifest.json)
  • Note the “–ship” option in the command. It minifies files in the package. You can ignore it if you are deploying it to non-production environments.
  • Upload .sppkg file from SharePoint solution folder to Apps for SharePoint library. Click on Trust.

You can find the full working solution at GitHub. Clone or download the zip. All you have to do is change CDN path to a SP library folder path (in manifest.json).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu