1.6.0 Workbench issue - workaround not quite working

Question

1.6.0 Workbench issue - workaround not quite working

thomasberman opened this issue 6 years ago · 23 comments

Hi Waldek,

I was reading a thread elsewhere yesterday about this, but I seem to have lost it, so now I'm posting here. I was unable to solve the workbench issue for 1.6.0 using the documentation. Like some others, I tried the 1.5.0 workaround, and was able to get to the workbench via the full URL.

I'm experiencing a strange issue though. I manage to get to the workbench via https://localhost:4321/temp/workbench.html, but the page shows up completely empty. It navigates to workbench, the tab gets a title and favicon etc, but the workbench simply doesn't render. I just spun up the same project in a VM where I have the framework tools globally installed, and it served to the workbench just fine.

I wonder if you've seen anything like this before.

Answer 1 · 2018-09-27T19:31:48.000Z

When the workbench loads with an empty page, do you get any errors in the console or on the network tab in the browser's dev tools?

Answer 2 · 2018-09-28T11:36:03.000Z

Looks like there are a few errors in the console. It doesn't seem to be able to load files from @microsoft/sp-webpart-workbench and @microsoft/sp-loader

I tried running an npm install on those packages and I nearly the same errors.

Answer 3 · 2018-09-28T17:42:11.000Z

Have you tried navigating to these URLs in the browser?

Answer 4 · 2018-09-28T17:43:08.000Z

Also, to double check, are you executing gulp serve or gulp serve --nobrowser? There is a known issue that causes some packages not to be copied when using the --nobrowser switch.

Answer 5 · 2018-10-04T11:33:52.000Z

Seems to be related to SharePoint/sp-dev-docs#2501
I saw some of the above issues when I didn't open the workbench through https://localhost:5432/workbench but used https://localhost:4321/temp/workbench.html

Answer 6 · 2018-10-13T19:20:17.000Z

Which version of Windows are you guys using? @YannickRe @thomasberman

Answer 7 · 2018-10-13T19:45:52.000Z

I'm running Windows 10 1803 (April 2018 update) build 17134

Answer 8 · 2018-10-14T13:39:09.000Z

It turns out that the problem has to do with the difference in Windows and Docker and how they deal with 0.0.0.0.

A temporary workaround for v1.6.0:

In config\write-manifests.json, add "debugBasePath": "https://localhost:4321/":

{
  "$schema": "https://developer.microsoft.com/json-schemas/spfx-build/write-manifests.schema.json",
  "cdnBasePath": "<!-- PATH TO CDN -->",
  "debugBasePath": "https://localhost:4321/"
}

In node_modules\@microsoft\sp-build-web\lib\SPWebBuildRig.js change lines 83-85 from:

spBuildCoreTasks.writeManifests.mergeConfig({
  debugBasePath: `${serve.taskConfig.https ? 'https' : 'http'}://${serve.taskConfig.hostname}:${serve.taskConfig.port}/`
});

to:

if (!spBuildCoreTasks.writeManifests.taskConfig.debugBasePath) {
  spBuildCoreTasks.writeManifests.mergeConfig({
    debugBasePath: `${serve.taskConfig.https ? 'https' : 'http'}://${serve.taskConfig.hostname}:${serve.taskConfig.port}/`
  });
}

With these changes, by following the regular instructions (in config\serve.json adding "hostname:" "0.0.0.0") you should be able to have a functional workbench.

I'll report the bug to Microsoft and hopefully it will be fixed in the futures of SPFx.

Answer 9 · 2018-10-16T14:50:40.000Z

Hi Waldek,

Thanks for looking into this. I'm still not able to get the workbench working. I get these errors from 5432/workbench:

and these errors from 4321/temp/workbench.html:

At first I was getting an error from Node during gulp serve that @microsoft/sp-webpart-workbench wasn't installed, so I installed it via npm, which has gotten me to this point.

When I try to load the workbench in SharePoint (/_layouts/15/workbench.aspx), I actually see my web part, but I get these errors when I try to add them to the page.

Answer 10 · 2018-10-16T17:03:53.000Z

How about you try to clear everything and try from scratch:

run gulp clean
delete node_modules
run npm install
run gulp serve
Can you still repro the issue?

Answer 11 · 2018-10-16T18:55:30.000Z

I also still have issues, so I'll write down all my scenario's.

Starting from scratch, running gulp serve

This error shows in Gulp console (probably normal, since it's docker container without app)
(node:20) UnhandledPromiseRejectionWarning: Error: Exited with code 3 at ChildProcess.cp.once.code (/usr/app/spfx/node_modules/opn/index.js:84:13) at Object.onceWrapper (events.js:317:30) at emitTwo (events.js:126:13) at ChildProcess.emit (events.js:214:7) at maybeClose (internal/child_process.js:925:16) at Socket.stream.socket.on (internal/child_process.js:346:11) at emitOne (events.js:116:13) at Socket.emit (events.js:211:7) at Pipe._handle.close [as _onclose] (net.js:557:12) (node:20) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:20) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Open with https://localhost:5432/workbench, get redirected and this error shows in Edge dev console
Multiple refreshes of https://localhost:4321/temp/workbench.html, sometimes it works correctly and sometimes this error shows in Edge console:
In that case, Gulp console shows this:
Error: ENOENT: no such file or directory, open '/usr/app/spfx/temp/workbench-packages/@microsoft_sp-webpart-workbench/lib/api/workbenchInit.js'
Online workbench never has an issue

Stopping previous serve and running gulp serve again

Showing the same error for UnhandledPromiseRejectionWarning
Accessing https://localhost:5432/workbench shows this in the browser (NOT the dev console):
Error: ENOENT: no such file or directory, symlink '/usr/app/spfx/node_modules/@microsoft/sp-webpart-workbench' -> '/usr/app/spfx/temp/workbench-packages/@microsoft_sp-webpart-workbench' at Object.fs.symlinkSync (fs.js:1014:18) at WorkbenchPage._getUrlForPackagePath (/usr/app/spfx/node_modules/@microsoft/sp-webpart-workbench/lib/api/WorkbenchPage.js:166:17) at WorkbenchPage._generateWorkbenchPageContent (/usr/app/spfx/node_modules/@microsoft/sp-webpart-workbench/lib/api/WorkbenchPage.js:33:39) at WorkbenchPage.handleWorkbenchRequest (/usr/app/spfx/node_modules/@microsoft/sp-webpart-workbench/lib/api/WorkbenchPage.js:25:51) at Layer.handle [as handle_request] (/usr/app/spfx/node_modules/express/lib/router/layer.js:95:5) at next (/usr/app/spfx/node_modules/express/lib/router/route.js:137:13) at Route.dispatch (/usr/app/spfx/node_modules/express/lib/router/route.js:112:3) at Layer.handle [as handle_request] (/usr/app/spfx/node_modules/express/lib/router/layer.js:95:5) at /usr/app/spfx/node_modules/express/lib/router/index.js:281:22 at Function.process_params (/usr/app/spfx/node_modules/express/lib/router/index.js:335:12) at next (/usr/app/spfx/node_modules/express/lib/router/index.js:275:10) at _setJSONResponseContentTypeMiddleware (/usr/app/spfx/node_modules/@microsoft/gulp-core-build-serve/lib/ServeTask.js:120:9) at Layer.handle [as handle_request] (/usr/app/spfx/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/usr/app/spfx/node_modules/express/lib/router/index.js:317:13) at /usr/app/spfx/node_modules/express/lib/router/index.js:284:7 at Function.process_params (/usr/app/spfx/node_modules/express/lib/router/index.js:335:12)
/temp folder only has the folders @microsoft_sp-loader and @microsoft_sp-webpart-workbench (not react and react-dom). They show up as files in Windows and as folders in Docker. Moving into those folders in Docker, results in the following error:
bash: cd: @microsoft_sp-webpart-workbench: No such file or directory
Online workbench never has an issue

At this point I'm thinking: stuff doesn't get cleared correctly when stopping gulp serve so on a new serve it cannot copy the packages into the temp folder correctly. So gulp clean!
Stopping previous serve and running gulp clean

Gulp console return following error:
[18:35:53] Error - 'clean' sub task errored after 70 ms ENOTEMPTY: directory not empty, rmdir '/usr/app/spfx/temp/workbench-packages' [18:35:53] 'clean' errored after 73 ms [18:35:53] [18:35:53] ==================[ Finished ]================== Error - 'clean' sub task errored after 70 ms ENOTEMPTY: directory not empty, rmdir '/usr/app/spfx/temp/workbench-packages'
Manual deletion in Windows, following error:
Folder access denied, you need permissions to delete this folder
Manual deletion in Docker image, following error:
spfx@spfx:/usr/app/spfx/temp$ rm -r workbench-packages/ rm: cannot remove 'workbench-packages/@microsoft_sp-loader': No such file or directory rm: cannot remove 'workbench-packages/@microsoft_sp-webpart-workbench': No such file or directory rm: cannot remove 'workbench-packages/': Directory not empty
Go figure...

Stopping Docker

temp directory gets cleaned automatically...
Run gulp serve, start at the beginning of this post again...

Starting from scratch, running gulp serve --nobrowser

Obviously the error of UnhandledPromiseRejectionWarning doesn't show
Everything else is similar as the Starting from scratch, running gulp serve edition
Redoing the other steps with --nobrowser makes no difference
Online workbench has no issues

With the Online workbench, atleast I can do Docker and start developing. I hope you can find a fix for the local workbench, but I would totally understand if you let it pass.

Answer 12 · 2018-10-16T19:41:08.000Z

One thing at a time:

(node:20) UnhandledPromiseRejectionWarning: Error: Exited with code 3 at ChildProcess.cp.once.code (/usr/app/spfx/node_modules/opn/index.js:84:13)

As you suspect, this is caused because gulp is running in docker and there is no app to use to open a webpage. This can be ignored.

...random errors

I've seen the same, where at some point it starts working. So far I was unable to find the reason for this behavior.

stuck in temp

I've also noticed this one and came to the same conclusion as you have: stop Docker, file disappears, restart Docker, run gulp serve, start from the beginning

I can spend some more time to see if I can find out anything more about why it's behaving the way it is. One thing I hope for, is that it's not something else altogether related specifically to Docker for Windows, which would make solving the issue much harder.

Let's keep this issue open for future reference and thanks for helping out with the research

Answer 13 · 2018-10-16T19:47:26.000Z

I’m blaming Docker for Windows, so I’m totally ok for leaving it as it is. Tried creating a Windows Server Nano image with SPFx, ran into other Docker for Windows issues so I’m sure this product has issues...

Answer 14 · 2019-01-10T15:06:50.000Z

Using Docker Desktop v2.0.0.0-win81 (29211) - created a docker image with SPFx tools from 4.7.2-runtime-windowsservercore-ltsc2019 base image.
npm@5.6.0, node@v8.9.4
+-- @microsoft/generator-sharepoint@1.7.1
+-- gulp@4.0.0
+-- windows-build-tools@5.1.0
`-- yo@2.0.5

yo successfully scaffolds a SPFx project.
Applied fixes above prior to running gulp.
gulp serve successfully loads project. I can view Source for workbench.html but workbench.html fails to render properly.

Local workbench issue:
Issue appears to be with symbolic links on host? Is Docker Desktop with windows base image for SPFx Local workbench viable? I realize many moving parts here - just pausing to see if I should be investing any more time to make this work.

note: Success when using SharePoint Online workbench (_layouts/15/workbench.aspx)

Local workbench issue:
[09:37:05] Starting subtask 'write-manifests'...
[09:37:06] Finished subtask 'write-manifests' after 1.21 s
[09:37:06] Starting subtask 'reload'...
[09:37:06] Finished subtask 'reload' after 4.03 ms
Request: [::ffff:192.168.108.128] '/workbench'
Request: '/temp/workbench.html'
Request: '/temp/manifests.js'
Request: '/temp/workbench-packages/@microsoft_sp-loader/dist/sp-loader-assembly_default.js'
Error: UNKNOWN: unknown error, stat 'C:\spfx-solution\temp\workbench-packages@microsoft_sp-loader\dist\sp-loader-assembly_default.js'
Request: '/temp/workbench-packages/@microsoft_sp-webpart-workbench/lib/api/workbenchInit.js'
Error: UNKNOWN: unknown error, stat 'C:\spfx-solution\temp\workbench-packages@microsoft_sp-webpart-workbench\lib\api\workbenchInit.js'
Request: '/temp/workbench-packages/@microsoft_sp-webpart-workbench/lib/api/assets/server-icon.png'
Error: UNKNOWN: unknown error, stat 'C:\spfx-solution\temp\workbench-packages@microsoft_sp-webpart-workbench\lib\api\assets\server-icon.png

Answer 15 · 2019-01-10T22:15:23.000Z

@thomasberman, I am using node@v8.9.4 with @microsoft/generator-sharepoint@1.7.0, and I can reproduce what you've experienced, except I always get the local workbench work at the first time right after I create a new project and run "gulp serve". If I exit the container, and get back again, I can reproduce the same error.

I found if I restart docker, then create a new container, and run "gulp serve", local workbench works for me, but it's just a little annoying.

Answer 16 · 2020-03-09T18:17:57.000Z

Getting error "EADDRINUSE" while running "gulp serve". Any suggestions to fix this?

$ gulp serve
Build target: DEBUG
[18:12:19] Using gulpfile /usr/app/spfx/gulpfile.js
[18:12:19] Starting gulp
[18:12:19] Starting 'serve'...
[18:12:19] Starting subtask 'configure-sp-build-rig'...
[18:12:19] Finished subtask 'configure-sp-build-rig' after 51 ms
[18:12:19] Starting subtask 'spfx-serve'...
[18:12:19] [spfx-serve] To load your scripts, use this query string: ?debug=true&noredir=true&debugManifestsFile=https://0.0.0.0:4321/temp/manifests.js
[18:12:22] Starting server...
Starting api server on port 5432.
Registring api: /workbench
Registring api: /
[18:12:26] Finished subtask 'spfx-serve' after 7.78 s
[18:12:26] Starting subtask 'pre-copy'...
[18:12:27] Finished subtask 'pre-copy' after 676 ms
[18:12:27] Starting subtask 'copy-static-assets'...
[18:12:27] Starting subtask 'sass'...
{ Error: listen EADDRINUSE: address already in use :::5432
at Server.setupListenHandle [as _listen2] (net.js:1280:14)
at listenInCluster (net.js:1328:12)
at Server.listen (net.js:1415:7)
at SpfxServeTask.executeTask (/usr/app/spfx/node_modules/@microsoft/gulp-core-build-serve/lib/ServeTask.js:70:65)
at SpfxServeTask.executeTask (/usr/app/spfx/node_modules/@microsoft/sp-build-core-tasks/lib/spfxServe/SpfxServeTask.js:41:22)
at Promise (/usr/app/spfx/node_modules/@microsoft/gulp-core-build/lib/tasks/GulpTask.js:171:31)
at new Promise ()
at SpfxServeTask.execute (/usr/app/spfx/node_modules/@microsoft/gulp-core-build/lib/tasks/GulpTask.js:163:16)
at _executeTask (/usr/app/spfx/node_modules/@microsoft/gulp-core-build/lib/index.js:356:44)
at output.then (/usr/app/spfx/node_modules/@microsoft/gulp-core-build/lib/index.js:254:44)
at process._tickCallback (internal/process/next_tick.js:68:7)
at Function.Module.runMain (internal/modules/cjs/loader.js:834:11)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)
code: 'EADDRINUSE',
errno: 'EADDRINUSE',
syscall: 'listen',
address: '::',
port: 5432 }
[18:12:27] Error - Unknown
listen EADDRINUSE: address already in use :::5432
{ Error: listen EADDRINUSE: address already in use 0.0.0.0:4321
at Server.setupListenHandle [as _listen2] (net.js:1280:14)
at listenInCluster (net.js:1328:12)
at doListen (net.js:1461:7)
at process._tickCallback (internal/process/next_tick.js:63:19)
at Function.Module.runMain (internal/modules/cjs/loader.js:834:11)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)
code: 'EADDRINUSE',
errno: 'EADDRINUSE',
syscall: 'listen',
address: '0.0.0.0',
port: 4321 }
[18:12:27] Error - Unknown
listen EADDRINUSE: address already in use 0.0.0.0:4321
[18:12:27] Opening https://localhost:5432/workbench using the default OS app
(node:252) UnhandledPromiseRejectionWarning: Error: Exited with code 3
at ChildProcess.cp.once.code (/usr/app/spfx/node_modules/opn/index.js:84:13)
at Object.onceWrapper (events.js:286:20)
at ChildProcess.emit (events.js:198:13)
at maybeClose (internal/child_process.js:982:16)
at Socket.stream.socket.on (internal/child_process.js:389:11)
at Socket.emit (events.js:198:13)
at Pipe._handle.close (net.js:607:12)
(node:252) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:252) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
[18:12:27] Finished subtask 'copy-static-assets' after 278 ms
[18:12:28] ==================[ Finished ]==================
Error - Unknown
listen EADDRINUSE: address already in use :::5432
Error - Unknown
listen EADDRINUSE: address already in use 0.0.0.0:4321
[18:12:28] Finished subtask 'sass' after 1.23 s
[18:12:28] Starting subtask 'tslint'...
[18:12:38] [tslint] tslint version: 5.12.1
[18:12:38] Starting subtask 'tsc'...
[18:12:38] [tsc] typescript version: 3.3.4000
[18:12:38] Project spfx version:0.0.1
[18:12:38] Build tools version:3.12.1
[18:12:38] Node version:v10.18.1
[18:12:38] Total duration:1.55 min
[18:12:38] Task errors:4
[18:12:58] Finished subtask 'tsc' after 21 s
[18:12:59] Finished subtask 'tslint' after 31 s
[18:12:59] Starting subtask 'post-copy'...
[18:12:59] Finished subtask 'post-copy' after 580 μs
[18:12:59] Starting subtask 'collectLocalizedResources'...
[18:12:59] Finished subtask 'collectLocalizedResources' after 7.76 ms
[18:12:59] Starting subtask 'configure-webpack'...
[18:13:08] Finished subtask 'configure-webpack' after 8.55 s
[18:13:08] Starting subtask 'webpack'...
[18:13:32] Finished subtask 'webpack' after 24 s
[18:13:32] Starting subtask 'configure-webpack-external-bundling'...
[18:13:32] Finished subtask 'configure-webpack-external-bundling' after 1.43 ms
[18:13:32] Starting subtask 'copy-assets'...
[18:13:32] Finished subtask 'copy-assets' after 103 ms
[18:13:32] Starting subtask 'write-manifests'...
[18:13:45] Finished subtask 'write-manifests' after 13 s
[18:13:45] Starting subtask 'reload'...
[18:13:45] Finished subtask 'reload' after 1.85 ms

Answer 17 · 2020-03-10T18:11:50.000Z

Could it be that there is another process running on port 5432 on your host?

Answer 18 · 2020-03-10T18:26:09.000Z

I just ran below command on my system and did not find any process running on 5432 port. any other idea?
netstat -a | findstr 5432

Answer 19 · 2020-03-11T18:14:20.000Z

What about 4321?

Answer 20 · 2020-03-11T18:26:37.000Z

same with 4321. Didn't find any rpcoess

netstat -a | findstr 4321

Answer 21 · 2020-03-13T18:59:16.000Z

Could it be that you have another SPFx docker container running in the background?

Answer 22 · 2022-01-05T17:08:52.000Z

Is there still an issue or could we close it?

Answer 23 · 2022-01-07T09:54:40.000Z

Closing due to lack of reply