pnp/docker-spfx

Workaround in SPWebBuildRig.js to access local workbench on Windows no longer works

Yvand opened this issue ยท 8 comments

Yvand commented

I think it started with @microsoft/generator-sharepoint@1.12.1:
SPWebBuildRig.js changed significantly and I couldn't find how to apply the workaround anymore.

I did a few (unsuccessful) tests:
In node_modules/@microsoft_sp-webpart-workbench/local-workbench/manifests.js, I tried to replace this:

manifest.loaderConfig.internalModuleBaseUrls = [manifestsFileUrl];

by this:

manifest.loaderConfig.internalModuleBaseUrls = ["https://localhost:4321/dist/"];

But sadly it has no effect.
I have very little experience with node/npm/bundle, so it's possible I missed something very simple or obvious :)

I'm having the same problem.
I can't get the workbench to work with version 1.12.1, and the workaround in SPWebBuildRig.js seems to no longer be applicabile
Any updates?

I'm having the same problem.
I can't get the workbench to work with version 1.12.1, and the workaround in SPWebBuildRig.js seems to no longer be applicabile
Any updates?

I'm having the same problem too; the object spBuildCoreTasks.writeManifests does not exist anymore.

Can somebody advise?
Thank you

We've identified the necessary changes to v1.12.0+ here: #54. Could you please check if it works for you?

It works.
Just one note:
the query string to use to load the scripts in a SP page should be (or, at least, needs to be, to works in my test)
?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/manifests.js
spfx-serve seems to print out:
[spfx-serve] To load your scripts, use this query string: ?debug=true&noredir=true&debugManifestsFile=https://0.0.0.0:4321/temp/manifests.js

To have the right query string printed out by spfx-serve, I had to change the line 108 in node_modules@microsoft\sp-build-core-tasks\lib\spfxServe\SpfxServeTask.js
from:
return new url_1.URL(${taskConfig.https ? 'https' : 'http'}://${taskConfig.hostname}:${taskConfig.port}/);
to:
return new url_1.URL(${taskConfig.https ? 'https' : 'http'}://localhost:${taskConfig.port}/);

Am I the only one encountering this issue?

@whitegenie are you using the image on Windows or macOS?

I'm using the image 1.12.1 on Windows 10

@Yvand, @whitegenie, @MarcoAlfani now the instructions for 1.12.1 version are updated in Readme. I guess we could close the issue?

Yvand commented

Yep, all good for me