Developing SPFx solutions using containers - Introduction


This is the first of 4 articles on using containers for SharePoint Framework (SPFx) development.

Disclaimer

While I have learned a lot about containers over the last 2 years, I do not claim to be the final authority on this topic. My goal over these next 4 articles is share what I have learned and how I use that knowledge in my daily life as a SPFx developer. Containers are not just for SPFx but work on many developer technologies. In fact, I used containers, primarily Codespaces, to write this blog, which uses Hugo/Go. I encourage you to do the research and make your life easier.

The following links will be updated as articles become available.

Why are containers important

One of the most challenging aspects of developing solutions using the SharePoint Framework (SPFx) is setting up the development environment. Each version of SPFx only works with specific versions of NodeJS, so working with project that was created in previous versions of SPFx quickly becomes a headache. That said, there are several strategies to help you manage these environments, including using remote containers. Recent improvements to how remote containers work can simplify how you manage your projects.

I have written several posts on how to set up developer environments and if you are setting up an environment to build solutions using the latest version of SPFx, it is fairly straight forward, as I outline in the blog post here. The challenge is that over time, as SPFx versions depend on newer technology, your environment may no longer be compatible with the SPFx requirements. While you can upgrade your environment, what happens when you have to make a change to a solution built in a previous version of SPFx that uses packages that are not compatible with your environment? You will quickly realize that having a single dev environment will lead to you spending a lot of time solving compatibility errors or constantly having to upgrade your old solutions to the latest version of SPFx.

Node Version Manager to the rescue

The first piece of advice you will hear from any experienced SPFx developer is that you have to use Node Version Manager (nvm) to allow multiple NodeJs environments to exists on one device. While NVM is not a container technology, it works similarly to containers, so that is why I have included it here.

If you take nothing else away from this series on how to make life easier as a SPFx developer, please implement NVM into your tools. All of the container technologies in this series also use NVM in the actual containers. I have yet to meet a developer that is using NVM that would ever go back to their life before NVM.

Since you can only have one instance/version of NodeJs installed on your device, changing that version is a pain that you will tire of after the first time. NVM solves this issue by creating copies of different versions of NodeJS environments and letting you swap out the active instance. Each instance is tied to a specific version of NodeJS and everything you install in that instance is linked to the instance. So you can have multiple NodeJS environments that are completely independent of each other, with unique sets (and versions) of the developer tools you need, including SPFx.

I won’t go into detail on how to set up NVM as I have covered this in the SharePoint Framework Quick Start article. Andrew Connell also has some detailed articles on setting up enviroments for specific SPFx versions. This is done via NVM and I have included links in the References section below.

Once you have NVM installed on your device, changing to an entirely new development environment is just a few commands away. If you need to work on a solution that was developed with a previous version of SPFx, you can determine which environment you need for the specific SPFx version by using the compatibility chart found in SP Docs or in the Tahoe Ninjas blog. You can then set up that environment by installing the correct version of NodeJs. Each instance of NodeJs is a self contained environment, so you will need to install the main developer tools as global packages in each environment. If you are creating solutions in this new environment, you’ll need to install gulp-cli, the yeoman package, and the generator for the specific version of SPFx you will be creating. If you are working on an existing solution, the minimum you will need is gulp-cli. For exmple, if you need to work in a solution the requires NodeJs v10.x, the following commands are all you need to set up that environment.

nvm install 10.24.1
npm install gulp-cli -g

Once you are set up, change your path to your solution folder, install the solution dependencies using “npm install” and you are ready to work in the solution.

Remote Containers

Remote containers is a generic term for any environment that is not on your local device. More accurately, the environment is not running against your local file system. The best way I have found to use this technology is through VS Code extensions. I use three of these container solutions

  • WSL, accessed through the Remote-WSL extension
  • Docker, accessed through the Remote-Containers extension, and
  • Codespaces, accessed through the Github Codespaces extension

I will cover each of these solutions in upcoming articles and will update the links at the top of this article as articles become available.

References for this article

See ya soon!!!