Docker images for SharePoint Framework
50K+
Docker images for running SharePoint Framework.
Run once, to create the folder that stores the development certificate (if Docker creates it instead, it's owned by root and the container can't write to it):
mkdir -p ~/.rushstack
Then, each time, from your project folder:
docker run -it --rm --name ${PWD##*/} -u node -p 4321:4321 -p 35729:35729 -v "$PWD":/usr/app/spfx -v ~/.rushstack:/home/node/.rushstack m365pnp/spfx:latest
docker run -it --rm --name (Split-Path -Leaf $PWD) -u node -p 4321:4321 -p 35729:35729 -v "${PWD}:/usr/app/spfx" -v "${HOME}\.rushstack:/home/node/.rushstack" m365pnp/spfx:latest
docker run -it --rm --name spfx-helloworld -u node -p 4321:4321 -p 35729:35729 -v "%cd%":/usr/app/spfx -v "%USERPROFILE%\.rushstack":/home/node/.rushstack m365pnp/spfx:latest
The .rushstack mount keeps the development certificate on your host, so it survives --rm and only has to be trusted once.
After the container started you can work with it the same way you would work with SharePoint Framework installed on your host. To create a new SharePoint Framework project in the container command line execute:
yo @microsoft/sharepoint
All files scaffolded by the generator will be stored in your project directory on your host from where you can commit them to source control.
Before running heft start, edit config/serve.json in your project so the dev server listens on all interfaces. By default it listens on localhost inside the container, which the published ports can't reach. Add ipAddress, and remove hostname if present (it takes precedence over ipAddress):
{
"$schema": "https://developer.microsoft.com/json-schemas/spfx-build/spfx-serve.schema.json",
//...
"ipAddress": "0.0.0.0"
}
The first heft start creates a certificate authority at ~/.rushstack/rushstack-ca.pem (mounted from your host). Trust it once on the machine where your browser runs, then restart the browser:
From WSL, for a browser on Windows:
certutil.exe -user -addstore Root "$(wslpath -w ~/.rushstack/rushstack-ca.pem)"
From PowerShell on Windows:
certutil -user -addstore Root "$HOME\.rushstack\rushstack-ca.pem"
On macOS:
security add-trusted-cert -r trustRoot -k ~/Library/Keychains/login.keychain-db ~/.rushstack/rushstack-ca.pem
To close the container in the container command line run:
exit
When running yo @microsoft/sharepoint you get an error that the container is unable to write files to the disk. In most cases this is caused by the drive not being shared in Docker. Go to Docker > Settings > Sharing to enable sharing the drive where your project is located.
Projects scaffolded with --package-manager pnpm by generator 1.24.0 fail heft build with TS2416: Property 'dataVersion' ... is not assignable, because pnpm installs two copies of @microsoft/sp-core-library. npm-based projects are not affected.
When using the container with SharePoint Framework >=v1.14.0, you can't access the local workbench or can't load bundles in the hosted workbench. This is caused by the default mapping of the workbench to localhost, which isn't accessible outside of the container. To fix it, map the workbench to 0.0.0.0, by modifying the ./config/serve.json file in your SharePoint Framework project to:
{
"$schema": "https://developer.microsoft.com/json-schemas/core-build/serve.schema.json",
//...
"ipAddress": "0.0.0.0"
}
If serve.json also contains a hostname property, remove it: it takes precedence over ipAddress. Keep browsing to https://localhost:4321 from the host.
When using the container with SharePoint Framework >=v1.6.0, you can't access the local workbench or can't load bundles in the hosted workbench. This is caused by the default mapping of the workbench to localhost, which isn't accessible outside of the container. To fix it, map the workbench to 0.0.0.0, by modifying the ./config/serve.json file in your SharePoint Framework project to:
{
"$schema": "https://developer.microsoft.com/json-schemas/core-build/serve.schema.json",
//...
"hostname": "0.0.0.0"
}
Modify node_modules\@microsoft\spfx-heft-plugins\lib\plugins\webpackConfigurationPlugin\WebpackConfigurationGenerator.js:393
const debugBaseUrl = `${serveConfig.https ? 'https' : 'http'}://${serveConfig.hostname || 'localhost'}:${serveConfig.port || 4321}/${distFolderName}/`;
to:
const debugBaseUrl = `${serveConfig.https ? 'https' : 'http'}://localhost:${serveConfig.port || 4321}/${distFolderName}/`;
Modify node_modules\@microsoft\spfx-heft-plugins\lib\plugins\webpackConfigurationPlugin\WebpackConfigurationGenerator.js:376
const debugBaseUrl = `${serveConfig.https ? 'https' : 'http'}://${serveConfig.hostname || 'localhost'}:${serveConfig.port || 4321}/dist/`;
to:
const debugBaseUrl = `${serveConfig.https ? 'https' : 'http'}://localhost:${serveConfig.port || 4321}/dist/`;
When using the container with SharePoint Framework >=v1.6.0 on Windows, you can't access the local workbench despite following the steps from the previous section. This has to do with Windows being unable to correctly access 0.0.0.0. To fix it, first, modify config\write-manifests.json to (add the debugBasePath property):
{
"$schema": "https://developer.microsoft.com/json-schemas/spfx-build/write-manifests.schema.json",
"cdnBasePath": "<!-- PATH TO CDN -->",
"debugBasePath": "https://localhost:4321/"
}
Then, open node_modules\@microsoft\sp-build-web\lib\SPWebBuildRig.js and change lines from:
spBuildCoreTasks.writeManifests.mergeConfig({
debugBasePath: `${serve.taskConfig.https ? 'https' : 'http'}://${serve.taskConfig.hostname}:${serve.taskConfig.port}/`
});
to (add the if statement):
if (!spBuildCoreTasks.writeManifests.taskConfig.debugBasePath) {
spBuildCoreTasks.writeManifests.mergeConfig({
debugBasePath: `${serve.taskConfig.https ? 'https' : 'http'}://${serve.taskConfig.hostname}:${serve.taskConfig.port}/`
});
}
Depending on the SPFx version the lines to replace are different:
| SPFx version | SPWebBuildRig.js lines to replace |
|---|---|
| 1.6.0, 1.7.0 or 1.7.1 | 83-85 |
| 1.8.0, 1.8.1 or 1.8.2 | 88-90 |
| 1.9.1 | 92-94 |
| 1.10.0 or 1.11.0 | 96-98 |
When using the container with SharePoint Framework v1.5.0, you can't access the local workbench or can't load bundles in the hosted workbench. This is caused by a change to the gulp-connect package used by the gulp serve task. To fix the issue, after scaffolding the project, in the code editor open the ./node_modules/gulp-connect/index.js file and change line 106 from:
return this.server.listen(this.port, this.host, (function(_this) {
to (remove the this.host argument):
return this.server.listen(this.port, (function(_this) {
Windows 10 Anniversary Update and Windows Server 2016 have native support for containers. At this moment Windows supports only containers built on Windows Server Core or Nano Server and you won't be able to run this container natively on Windows. Instead you should use Docker for Windows or Docker Toolbox.
Content type
Image
Digest
sha256:8dcec41ff…
Size
495.5 MB
Last updated
4 days ago
docker pull m365pnp/spfxPulls:
235
Oct 19 to Oct 25