GitHub codespaces + SPFx
In this blog post we will have a look at how we can use GitHub codespaces to do development related to SPFx. The concepts that are mentioned in this blog post run in parallel with the details shared in this brilliant article on Visual Studio codespaces by Paul Schaeflein.
In this 2 part series we will start by looking at:
- What GitHub codespaces are and how to create them. After that we create a simple SPFx webpart in GitHub codespaces.
- How to push the code of the SPFx webpart from GitHub codespaces to a repository in Azure DevOps.
Part 1 — GitHub Codespaces
What are GitHub codespaces?
GitHub codespaces are cloud hosted development environments that can be created very quickly so that we can start coding on a project right away. In terms of SPFx development we can think of GitHub codespaces as a preconfigured development environment (in the cloud) which has all the SPFx pre-requisites installed.
GitHub codespaces are currently in beta and access can be requested from here. During the beta stage each user can create a maximum of 2 codespaces.
Creating GitHub codespaces (need to request access first)
In order to create GitHub codespaces, we need a GitHub repository. Navigating to a repository and clicking on “Code” button and selecting “Open with codespaces” provides us an option to create a new codespace.
The new codespace (i.e. a development environment in cloud) that gets created will be based on Linux and will have version 12.x of node. More information on what is included in that codespace can be found here.
The newly created codespace will be automatically connected to the repository in GitHub. So if we add/remove files we can commit them back to the connected repository.
We cannot RDP into this codespace, instead we connect to only the code we need in the codespace from VS code (either from the browser or from the editor on our machines). We need a VS code extension named “GitHub Codespaces” to access codespaces.
GitHub codespaces for SPFx
When a GitHub codespace is created, by default it will have Node version 12.x. For SPFx development we need Node version 10.x. Also the codespace will not have the other components like yeoman, the SPFx generator etc which are needed for SPFx development.
There are different ways of making the codespace have the setup required for SPFx development i.e. personalizing the codespace as per our requirement. We will be looking at the Docker approach.
When a new codespace is being created, it will look for something called as dotfiles (files and folders beginning with a dot). We can define the required SPFx configuration in these dotfiles. We can achieve this is by creating a folder named “.devcontainer” and adding 2 files in it named “Dockerfile” and “devcontainer.json”.
Note: The configuration specified in these files will be applied only to a new codespace at the time of creation. It will not apply to existing codespace. So if you have created a new codespace without these files then it would be good to delete it or run the pre-requisites manually.
Please refer this article by Waldek Mastykarz to know about Docker and SPFx. Since a Docker file already exists for SPFx, we will be using that for our initial setup with a minor update.
This file contains information about the default settings of a codespace. One of the setting we need is what ports need to be forwarded from the codespace. So we will be defining those in this file. For SPFx we need ports 4321, 5432 and 35729 to be forwarded from the codespace.
Lets either create a new repository with only file in it (README.md) or open an existing SPFx repository. Let’s add a folder named “.devcontainer” in the repository at the root level.
In this folder lets add the following 2 files:
In the Dockerfile, we have specified the Node version as 10.22.0 and have also specified all the npm packages that need to be installed for SPFx development.
In the devcontainer.json we have specified that the Dockerfile needs to be used for creation of the codespace and we have specified the required ports that need to be forwarded.
Creating a codespace (need to request access first)
Now let’s create a codespace from this repository. For this all we have to do is click on “Code” button and select “Open with codespaces” and click “New codespace”.
This will start the process of creating the codespace which will involve looking at the “.devcontainer” folder for the configuration that we defined. We can see all the messages being logged related to installing the packages.
Once finished, we will see VS code opened in browser with the code in the repository. We can see the “.devcontainer” folder and other files present in the repository.
If we open the terminal (Ctrl + ‘) and type “node -v” we can see that the version is 10.22.0 as specified in the “Dockerfile”.
If we open the Remote explorer extension and have a look at the forwarded ports section, we can see the 3 ports forwarded that we defined in “devcontainer.json”.
We can continue the next steps in the browser, however I prefer doing it in the VS code editor. So let’s open VS code and install the “GitHub codespaces” extension if not installed. After signing into codespaces with our GitHub accounts we will be able to see the codespace that was created earlier.
Connect to the codespace by clicking on the connect button to load the code.
Now we are in the familiar territory. So let’s open the terminal in VS code and start developing SPFx solutions with our favourite command
yo @microsoft/sharepoint .
Before testing the solution we need to make sure that the dev certificate is trusted. To do that, please follow this article by Paul Schaeflein.
One nice thing to think/feel about is that there is no “node_modules” folder of this project on our machines now!
If we want to store the above code in Azure DevOps instead of GitHub then in the next we will look at how to push the code from GitHub codespaces to a repository in Azure DevOps.