pnp/docker-spfx

SPFx:1.13.1 - workbench issue

necik11 opened this issue ยท 7 comments

Unfortunately my SPFX 1.13.1 workbench on my SHP Online does not work.
I'll try to put steps here that I'm doing maybe I'm doing something wrong:

First I downloaded the image:
docker pull waldekm / spfx: 1.13.1
npm install
set initialPage row ./config/serve.json from:microsoft
"initialPage": "https://shpapp.sharepoint.com/sites/myWeb/_layouts/workbench.aspx"

Then:
gulp serve
I got:

[20:19:57] Server started https://0.0.0.0:4321
[20:19:57] LiveReload started on port 35729
[20:19:57] Running server
[20:19:57] Opening https://shpapp.sharepoint.com/sites/myWeb/_layouts/workbench.aspx using the default OS app
(node: 1114) UnhandledPromiseRejectionWarning: Error: Exited with code 3
    at ChildProcess. <anonymous> (/usr/app/spfx/node_modules/opn/index.js:84:13)
    at Object.onceWrapper (events.js: 520: 26)
    at ChildProcess.emit (events.js: 400: 28)
    at ChildProcess.emit (domain.js: 537: 15)
    at maybeClose (internal / child_process.js: 1058: 16)
    at Socket. <anonymous> (internal / child_process.js: 443: 11)
    at Socket.emit (events.js: 400: 28)
    at Socket.emit (domain.js: 537: 15)
    at Pipe. <anonymous> (net.js: 686: 12)
    at Pipe.callbackTrampoline (internal / async_hooks.js: 130: 17)

What I've tried:
Known issues from https://hub.docker.com/r/waldekm/spfx:
"hostname": "0.0.0.0",

const debugBaseUrl = $ {serveConfig.https? 'https': 'http'}: // $ {serveConfig.hostname || 'localhost'}: $ {serveConfig.port || 4321} / dist / ;

I also tried this line from githubhelp. I am a little confused as has a different tutorial than hub.docker:

const debugBaseUrl = $ {serveConfig.https? 'https': 'http'}: // $ {serveConfig.hostname || 'localhost'}: $ {serveConfig.port || 4321} / $ {distFolderName} / ;
Anyway, neither worked.

On the web then i got:
Your web part will not appear in the toolbox. Please make sure "gulp serve" is running in a web part project. Please refresh the page once "gulp serve" is running.

The weird thing is that when I try to run:
https://0.0.0.0:4321
so i get:
ERR_EMPTY_RESPONSE

when I look in etc / hosts i have this from docker:

# Added by Docker Desktop
MyIp host.docker.internal
MyIp gateway.docker.internal
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section

I was trying to add debug after .aspx to load the manifest:

https://shpapp.sharepoint.com/sites/myWeb/_layouts/15/workbench.aspx?debug=true&noredir=true&debugManifestsFile=https://0.0.0.0:4321/temp/manifests.js

But i got this and i cant see webpart.
Error loading debug manifests.
Error: Script error for: https://0.0.0.0:4321/temp/manifests.js http://requirejs.org/docs/errors.html#scripterror

But when I try to change:
https://0.0.0.0:4321/temp/manifests.js
on
https://127.0.0.1:4321/temp/manifests.js
Although I also get a warning:
Your web part will not appear in the toolbox. Please make sure "gulp serve" is running in a web part project. Please refresh the page once "gulp serve" is running.
But at least I'm already looking for this Webpart:
image1
Unfortunately with error:
image2

Even if I give npm bundle --ship
npm package-solution --ship
and I deploy everything works ...

It seems again problem in docker. Docker and DNS problem?
Or am I doing something wrong? Thank you in advance for your reply :)

Thank you for sharing the information. The main problem is that by default the development web server running inside the container is mapped to localhost. Localhost isn't however exposed outside of the container, so it needs to be changed to 0.0.0.0. You do this by adjusting the hostname property, like you did. This has however a side-effect: Windows doesn't know how to handle 0.0.0.0. This is why you need to patch the node_modules\@microsoft\spfx-heft-plugins\lib\plugins\webpackConfigurationPlugin\WebpackConfigurationGenerator.js:393 file to:

const debugBaseUrl = `${serveConfig.https ? 'https' : 'http'}://localhost:${serveConfig.port || 4321}/${distFolderName}/`;

The trick here is to force the debugBaseUrl which is exposed on the host, to point to localhost instead of 0.0.0.0 which it would get from the hostname property by default.

One final tip: when running the gulp serve command, add to it --nobrowser. Since you're running the command inside a container which doesn't have a web browser, the command is throwing an error. You can avoid it by adding the --nobrowser switch to the command. I hope this helps.

First of all, thank you for the quick reply.

But I've already written that I tried to add this line (then the second line) to WebpackConfigurationGenerator.js and it didn't seem to work either.
Now I have tried to add --nobrowser to fix the error in the console and there really is no error in the console. To be sure, I looked on SHP online \ workbench and workbench already working. ๐Ÿ˜•

I think I was impatient because I was used to reflecting on code changes faster.

Now it occurs to me that I modified the code and the web party did not react to it. Only after turning gulp serve off and on again.

I think the change took effect and after: Finished subtask 'webpack' after 28 s
the change is displayed. So it is possible that I made some changes in the config files .. but I didn't wait 60s for the change ...

Here is the time in s:

[19:29:38] Starting server ...
[19:29:38] Finished subtask 'spfx-serve' after 3.61 s
[19:29:38] Starting subtask 'pre-copy' ...
[19:29:39] Finished subtask 'pre-copy' after 1.43 s
[19:29:39] Starting subtask 'copy-static-assets' ...
[19:29:39] Starting subtask 'sass' ...
[19:29:39] Server started https://0.0.0.0:4321
[19:29:40] LiveReload started on port 35729
[19:29:40] Running server
[19:29:42] Finished subtask 'sass' after 2.53 s
[19:29:42] Starting subtask 'tslint' ...
[19:29:42] [tslint] tslint version: 5.20.1
[19:29:42] Starting subtask 'tsc' ...
[19:29:42] [tsc] typescript version: 3.9.10
[19:29:47] Finished subtask 'copy-static-assets' after 7.47 s
[19:30:50] Finished subtask 'tslint' after 1.13 min
[19:30:50] Starting subtask 'post-copy' ...
[19:30:50] Finished subtask 'post-copy' after 498 ฮผs
[19:30:50] Starting subtask 'configure-webpack' ...
[19:30:57] Finished subtask 'configure-webpack' after 6.65 s
[19:30:57] Starting subtask 'webpack' ...
[19:31:25] Finished subtask 'webpack' after 28 s
[19:31:25] Starting subtask 'reload' ...
[19:31:25] Finished subtask 'reload' after 13 ms

So now everything probably works as it should, I just have to find out how to speed up the docker, because I have busy resources only at half the power, but the docker works slowly.
Thanks again for the solution and I will create an issue or topic with docker optimization elsewhere ๐Ÿ‘ ๐ŸŽ‰

Do I understand that all is working as intended?

If you're concerned about speed, you could look at https://github.com/s-KaiNet/spfx-fast-serve. It goes beyond what we'd include in the Docker image, but it could help you speed up the inner loop.

@necik11 here's some thought about performance of the system when you develop with Docker on Windows: https://www.linkedin.com/pulse/work-nodejs-windows-optimize-performance-aleksandr-sapozhkov/. Otherwise if everything else works fine, should we close the issue or are you wondering about some specific aspect of the problem above?

I'm sorry I didn't call for a long time (I'm very busy now), but to take it gradually.

  1. Do I understand that all is working as intended?
    a) It already worked for me (although I had to turn off the gulp and gulp serve again and wait 40 seconds, but it worked)
    b) unfortunately, when I tried it with a colleague, it didn't work again (the only change was that I tried more tutorials and I had a line there that is intended for SharePoint Framework> = 1.6.0 <= 1.11.0 on Windows, namely the line: "debugBasePath": "https: // localhost: 4321 /"), but I don't know if it will help or the problem will be elsewhere ... ๐Ÿ˜•

  2. I really looked at it for a while: spfx-fast-serve and again in the dock it doesn't work due to the localhost address, which it probably doesn't see with the docker .. maybe I should use the sp-rest-proxy, but I didn't get there.

  3. Optimize Performance!
    I would like to point out here, for example:
    a) "The easiest way to start using Docker in Windows is running it via PowerShell or CMD."
    Where via PowerShell I had a problem with the installation of the pnp/js library on 2 different PC/Laptop machines (permission problem) and I couldn't believe my eyes when my colleague released CMD and everything started to work ... ๐Ÿ˜ฎ
    b) gulp serve for SPFx I tried not on such a "good" laptop, but on a PC with: i7-6700 CPU @ 3.40GHz, and the time is around 40s ...
    c) As it is already written "reference paths are completely different and WSL disk system is not as natively integrated in Windows as your regular C: / drive", so it has already been written on other forums that therefore the more files it has to map more files and the duration is what. That's why they recommend moving the folder to a WSL disk ..., but how do you work with git ... I would have to do all this directly on Linux and thus containerization is useless or I'm wrong? ๐Ÿ˜”

And if you've read this far ... yes, it's a long read, but I'm trying to give feedback, so I hope it will help someone with similar problems in the future.
In conclusion, we can safely close this issue, as I decided to continue to use node/spfx on the HOST(PC), and use a new version for each project, and leave the old environment/projects in the dockerhub for possible later light modification (where I am temporarily satisfied with poor performance).

There have been so many problems all the time (which fortunately have been solved) that in the end there is a performance problem that looks unsolvable so far.

Maybe someone will be happier / more capable or I'll look into it when there is a little more time.
Anyway, thank you so much for the effort, ideas and articles.

If you move to WSL disk you will run git in WSL console and you will use integration of Visual Studio Code with the WSL disk. You can give it a try. Works even faster than using node/spfx on the host.

Closing due to lack of response