Sp-dev-docs: SPFX Local workbench not loading

[silambarsan]

Thank you for reporting an issue or suggesting an enhancement. We appreciate your feedback - to help the team to understand your needs, please complete the below template to ensure we have the necessary details to assist you.

Category

• [ ] Question
• [ ] Typo
• [ ] Bug
• [ ] Additional article idea

If you are planning to share a new feature request (enhancement / suggestion), please use SP Dev UserVoice at http://aka.ms/sp-dev-uservoice.

Expected or Desired Behavior

I have created a SPFX webpart as mentioned in the docs. Expected behaviour was to open the local workbench when I run gulp serve command. But Local workbench is not working. Earlier I had created few SPFX webparts, they were working fine. I had installed yo at dev level. Now I installed yo at global level

Observed Behavior

Local workbench page is loaded with Site can't be reached error message. Err_connection_reset

Steps to Reproduce

Create a SPFX webpart ( I am using node -v 6.10.2, yo sp generator -v 1.4.0, gulp -v 3.9.1)
Run gulp trust-dev-cert
Run gulp serve

Thanks for your contribution! Sharing is caring.

[waldekmastykarz]

Could you share the output of the gulp serve command? Which OS are you using?

[silambarsan]

Hi,

I am using Windows 8.1. Please find below the gulp serve log

gulp serve
Build target: DEBUG
[16:26:52] Using gulpfile \HelloWorldSolution\gulpfile.js
[16:26:52] Starting gulp
[16:26:52] Starting 'serve'...
[16:26:52] Starting subtask 'configure-sp-build-rig'...
[16:26:52] Finished subtask 'configure-sp-build-rig' after 13 ms
[16:26:52] Starting subtask 'spfx-serve'...
Starting api server on port 5432.
Registring api: /getwebparts
Registring api: /.
Registring api: /workbench
[16:26:52] Finished subtask 'spfx-serve' after 525 ms
[16:26:52] Starting subtask 'pre-copy'...
[16:26:52] Finished subtask 'pre-copy' after 10 ms
[16:26:52] Starting subtask 'copy-static-assets'...
[16:26:52] Starting subtask 'sass'...
[16:26:54] Server started https://localhost:4321
[16:26:54] LiveReload started on port 35729
[16:26:54] Opening https://localhost:5432/workbench using the default OS app
[16:26:54] Finished subtask 'sass' after 1.72 s
[16:26:54] Starting subtask 'tslint'...
[16:26:55] Starting subtask 'typescript'...
[16:26:55] [typescript] TypeScript version: 2.4.2
Warning: no-duplicate-case rule is deprecated. Replace your usage with the TSLint no-duplicate-switch-case rule.
Warning: valid-typeof rule is deprecated. Replace your usage with the TSLint typeof-compare rule.
[16:26:56] Finished subtask 'copy-static-assets' after 3.5 s
[16:26:57] Finished subtask 'tslint' after 3.14 s
[16:26:57] Finished subtask 'typescript' after 1.96 s
[16:26:57] Starting subtask 'ts-npm-lint'...
[16:26:57] Finished subtask 'ts-npm-lint' after 61 ms
[16:26:57] Starting subtask 'api-extractor'...
[16:26:57] Finished subtask 'api-extractor' after 1.94 ms
[16:26:57] Starting subtask 'post-copy'...
[16:26:57] Finished subtask 'post-copy' after 815 μs
[16:26:57] Starting subtask 'collectLocalizedResources'...
[16:26:57] Finished subtask 'collectLocalizedResources' after 20 ms
[16:26:57] Starting subtask 'configure-webpack'...
[16:26:58] Finished subtask 'configure-webpack' after 615 ms
[16:26:58] Starting subtask 'webpack'...
[16:27:00] Finished subtask 'webpack' after 1.79 s
[16:27:00] Starting subtask 'configure-webpack-external-bundling'...
[16:27:00] Finished subtask 'configure-webpack-external-bundling' after 1.44 ms
[16:27:00] Starting subtask 'copy-assets'...
[16:27:00] Finished subtask 'copy-assets' after 54 ms
[16:27:00] Starting subtask 'write-manifests'...
[16:27:00] Finished subtask 'write-manifests' after 584 ms
[16:27:00] Starting subtask 'reload'...
[16:27:00] Finished subtask 'reload' after 3.57 ms

Thank you.
Regards,
Silam

[waldekmastykarz]

Thanks for the output. Which browser are you using?

[silambarsan]

I am using chrome [Version 63.0.3239.132 (Official Build) (64-bit)]. But I have tried the same with IE 11 & opera. Same result on all browsers.

Thank you.

[waldekmastykarz]

Could it be that you have a firewall enabled that could be blocking your connection?

[iclanton]

@silambarsan - Did you check your firewall? ERR_CONNECTION_RESET usually points to a network interface or firewall issue.

Are you able to navigate directly to https://localhost:4321?

[nickpape]

Can you confirm the output of node --version ? We saw this exact issue with Node 8 & it will be fixed in the next SPFx release.

[Alek-S]

It looks like I'm having a similar issue.

@nickpape-msft for node v8 is there a workaround until the release? I tried the directions on Set up your SharePoint Framework development environment with node 8.9.4 on High Sierra, and the Hello World Guide

After I run gulp serve, i'm taken to https://localhost:5432/workbench via Chrome, but site can't be reached ERR_CONNECTION_CLOSED. @iclanton I can navigate to https://localhost:4321/ in which case I see a directory listing

Terminal output for gulp serve:

Build target: DEBUG
[13:58:58] Using gulpfile ~/dev/helloworld-webpart/gulpfile.js
[13:58:58] Starting gulp
[13:58:58] Starting 'serve'...
[13:58:58] Starting subtask 'configure-sp-build-rig'...
[13:58:58] Finished subtask 'configure-sp-build-rig' after 3.8 ms
[13:58:58] Starting subtask 'spfx-serve'...
Starting api server on port 5432.
Registring api: /getwebparts
Registring api: /*.*
Registring api: /workbench
[13:58:59] Finished subtask 'spfx-serve' after 183 ms
[13:58:59] Starting subtask 'pre-copy'...
[13:58:59] Finished subtask 'pre-copy' after 3.08 ms
[13:58:59] Starting subtask 'copy-static-assets'...
[13:58:59] Starting subtask 'sass'...
[13:58:59] Server started https://localhost:4321
[13:58:59] LiveReload started on port 35729
[13:58:59] Opening https://localhost:5432/workbench using the default OS app
[13:58:59] Finished subtask 'copy-static-assets' after 567 ms
[13:58:59] Finished subtask 'sass' after 560 ms
[13:58:59] Starting subtask 'tslint'...
[13:59:00] Starting subtask 'typescript'...
[13:59:00] [typescript] TypeScript version: 2.4.2
Warning: no-duplicate-case rule is deprecated. Replace your usage with the TSLint no-duplicate-switch-case rule.
Warning: valid-typeof rule is deprecated. Replace your usage with the TSLint typeof-compare rule.
[13:59:01] Finished subtask 'tslint' after 1.65 s
[13:59:01] Finished subtask 'typescript' after 1.03 s
[13:59:01] Starting subtask 'ts-npm-lint'...
[13:59:01] Finished subtask 'ts-npm-lint' after 4.78 ms
[13:59:01] Starting subtask 'api-extractor'...
[13:59:01] Finished subtask 'api-extractor' after 309 μs
[13:59:01] Starting subtask 'post-copy'...
[13:59:01] Finished subtask 'post-copy' after 127 μs
[13:59:01] Starting subtask 'collectLocalizedResources'...
[13:59:01] Finished subtask 'collectLocalizedResources' after 2.7 ms
[13:59:01] Starting subtask 'configure-webpack'...
[13:59:01] Finished subtask 'configure-webpack' after 138 ms
[13:59:01] Starting subtask 'webpack'...
[13:59:01] Finished subtask 'webpack' after 421 ms
[13:59:01] Starting subtask 'configure-webpack-external-bundling'...
[13:59:01] Finished subtask 'configure-webpack-external-bundling' after 413 μs
[13:59:01] Starting subtask 'copy-assets'...
[13:59:01] Finished subtask 'copy-assets' after 10 ms
[13:59:01] Starting subtask 'write-manifests'...
[13:59:02] Finished subtask 'write-manifests' after 180 ms
[13:59:02] Starting subtask 'reload'...
[13:59:02] Finished subtask 'reload' after 650 μs
^C[13:59:29] Server stopped
About to exit with code: 0
Process terminated before summary could be written, possible error in async code not continuing!
Trying to exit with exit code 1

package.json:

{
  "name": "helloworld-webpart",
  "version": "0.0.1",
  "private": true,
  "engines": {
    "node": ">=0.10.0"
  },
  "scripts": {
    "build": "gulp bundle",
    "clean": "gulp clean",
    "test": "gulp test"
  },
  "dependencies": {
    "@microsoft/sp-core-library": "~1.4.1",
    "@microsoft/sp-webpart-base": "~1.4.1",
    "@microsoft/sp-lodash-subset": "~1.4.1",
    "@microsoft/sp-office-ui-fabric-core": "~1.4.1",
    "@types/webpack-env": ">=1.12.1 <1.14.0"
  },
  "devDependencies": {
    "@microsoft/sp-build-web": "~1.4.1",
    "@microsoft/sp-module-interfaces": "~1.4.1",
    "@microsoft/sp-webpart-workbench": "~1.4.1",
    "gulp": "~3.9.1",
    "@types/chai": ">=3.4.34 <3.6.0",
    "@types/mocha": ">=2.2.33 <2.6.0",
    "ajv": "~5.2.2"
  }
}

[nickpape]

This actually should be fixed in the latest release. I am testing this right now. Could you try removing your node_modules and package.lock/npm-shrinkwrap.json files and re-running npm install?

In the meantime you could try running with with NODE_NO_HTTP2 environment variable (https://github.com/SharePoint/sp-dev-docs/issues/1002)

[LouFarho]

Using
set NODE_NO_HTTP2=1
gulp serve
Got it to work for me

[Alek-S]

Hey,

Thanks for the quick reply.

Gave that a go but still no go for me on https://localhost:5432/workbench.

Did the following:

1. Deleted node_modules folder
2. Deleted package-lock.json file
3. Added environmental variable for no http2 by putting export into my profile

-> printenv | grep NODE
NODE_NO_HTTP2=1

1. Run npm install
2. Run gulp serve

Get same ERR_CONNECTION_CLOSED. Maybe minimun version number for one of the microsoft modules needs to be bumped up in package.json file from above?

Build target: DEBUG
[15:47:00] Using gulpfile ~/dev/helloworld-webpart/gulpfile.js
[15:47:00] Starting gulp
[15:47:00] Starting 'serve'...
[15:47:00] Starting subtask 'configure-sp-build-rig'...
[15:47:00] Finished subtask 'configure-sp-build-rig' after 5.75 ms
[15:47:00] Starting subtask 'spfx-serve'...
Starting api server on port 5432.
Registring api: /getwebparts
Registring api: /*.*
Registring api: /workbench
[15:47:00] Finished subtask 'spfx-serve' after 313 ms
[15:47:00] Starting subtask 'pre-copy'...
[15:47:00] Finished subtask 'pre-copy' after 4.82 ms
[15:47:00] Starting subtask 'copy-static-assets'...
[15:47:00] Starting subtask 'sass'...
[15:47:01] Server started https://localhost:4321
[15:47:01] LiveReload started on port 35729
[15:47:01] Opening https://localhost:5432/workbench using the default OS app
[15:47:01] Finished subtask 'sass' after 660 ms
[15:47:01] Starting subtask 'tslint'...
[15:47:02] Starting subtask 'typescript'...
[15:47:02] [typescript] TypeScript version: 2.4.2
[15:47:02] Finished subtask 'copy-static-assets' after 1.42 s
Warning: no-duplicate-case rule is deprecated. Replace your usage with the TSLint no-duplicate-switch-case rule.
Warning: valid-typeof rule is deprecated. Replace your usage with the TSLint typeof-compare rule.
[15:47:03] Finished subtask 'tslint' after 1.91 s
[15:47:03] Finished subtask 'typescript' after 1.16 s
[15:47:03] Starting subtask 'ts-npm-lint'...
[15:47:03] Finished subtask 'ts-npm-lint' after 4.7 ms
[15:47:03] Starting subtask 'api-extractor'...
[15:47:03] Finished subtask 'api-extractor' after 259 μs
[15:47:03] Starting subtask 'post-copy'...
[15:47:03] Finished subtask 'post-copy' after 123 μs
[15:47:03] Starting subtask 'collectLocalizedResources'...
[15:47:03] Finished subtask 'collectLocalizedResources' after 2.48 ms
[15:47:03] Starting subtask 'configure-webpack'...
[15:47:03] Finished subtask 'configure-webpack' after 161 ms
[15:47:03] Starting subtask 'webpack'...
[15:47:03] Finished subtask 'webpack' after 584 ms
[15:47:03] Starting subtask 'configure-webpack-external-bundling'...
[15:47:03] Finished subtask 'configure-webpack-external-bundling' after 406 μs
[15:47:03] Starting subtask 'copy-assets'...
[15:47:03] Finished subtask 'copy-assets' after 11 ms
[15:47:03] Starting subtask 'write-manifests'...
[15:47:04] Finished subtask 'write-manifests' after 211 ms
[15:47:04] Starting subtask 'reload'...
[15:47:04] Finished subtask 'reload' after 885 μs
^C[15:48:43] Server stopped
About to exit with code: 0
Process terminated before summary could be written, possible error in async code not continuing!
Trying to exit with exit code 1

[LouFarho]

I am curious as to what was updated to support NodeJS 8.9.4
I take it there wasn't something we needed to update on our end?

[nickpape]

I am not sure this is the same issue as the one we fixed.

Essentially the fix was to ensure that one of our dependencies wasn't automatically using the HTTP2 library that is shipped with node (mostly because it is an "experimental" API, but also because it didn't work properly).

However, if activating the environment variable that disables the http2 module from being injected into the Node environment isn't working, it points to a different issue than the one we knew about.

[nickpape]

What browser are you using?

Can you go into the developer tab and into the networking section and see if there is anything interesting there. Perhaps a security error, or perhaps a response from the firewall ?

[nickpape]

@iclanton FYI

[Alek-S]

Chrome 64 by default. Checked console didn't see any log or error messages, network shows failed status when trying to load. Also attempted Safari to similar effect. I'm gonna try again from home as a sanity check in case it's network related and report back.

[nickpape]

Can you show the details of the failed workbench request by clicking on it?

Also, are you seeing a request (like Request: [::1] '/workbench') in the gulp serve logs when you navigate to https://localhost:5432/workbench?

Lastly, could you try going directly to https://localhost:4321/temp/workbench.html?

Does a workbench.html exist in your project's temp/ folder on disk?

[nickpape]

Can you paste your config/serve.json file?

[Alek-S]

@nickpape-msft going directly to https://localhost:4321/temp/workbench.html works.

config/serve.json

{
  "$schema": "https://dev.office.com/json-schemas/spfx-build/config.2.0.schema.json",
  "version": "2.0",
  "bundles": {
    "hello-world-web-part": {
      "components": [
        {
          "entrypoint": "./lib/webparts/helloWorld/HelloWorldWebPart.js",
          "manifest": "./src/webparts/helloWorld/HelloWorldWebPart.manifest.json"
        }
      ]
    }
  },
  "externals": {},
  "localizedResources": {
    "HelloWorldWebPartStrings": "lib/webparts/helloWorld/loc/{locale}.js"
  }
}

[nickpape]

Interesting.

@Alek-S that looks like config/config.json.. Could you double check?

[Alek-S]

You're right, my mistake:

serve.json below

{
  "$schema": "https://dev.office.com/json-schemas/core-build/serve.schema.json",
  "port": 4321,
  "https": true,
  "initialPage": "https://localhost:5432/workbench",
  "api": {
    "port": 5432,
    "entryPath": "node_modules/@microsoft/sp-webpart-workbench/lib/api/"
  }
}

[Alek-S]

so changing intialPage to temp/workbench.html assume is the fix then?

[nickpape]

Okay, that config file looks correct.

Also, if you delete the temp directory and re-run gulp serve does the /temp/workbench.html still get generated?

If the above is true (and the file is regenerated) then you could change you initial page as a workaround, although there still seems to be something weird if you can't go to localhost:5432/workbench.

[nickpape]

I am going to try this out on a Mac (OS X Yosemite 10.10.5) and see if I can repro the issue.

[Alek-S]

Confirming that removing temp directory and running gulp serve generates the temp folder.

[nickpape]

Fascinating. It didn't repro for me on Yosemite. @iclanton is going to see if we have any newer OSX installations lying around.

I'd stick with the workaround for right now, but I think this could be a firewall issue? We are using the native NodeJS https implementation to launch the API server.. Is this a corporate-configured computer?

Another thing you could check is run gulp serve then run lsof -n -i4TCP:5432 | grep LISTEN and lsof -n -i4TCP:4321| grep LISTEN.. We want to make sure they are both a "node" process with identical PID's. If the command for 5432 doesn't work then it could be possible there was an issue spinning up the server for that port.

e.g.

[andrewconnell]

Tested & confirmed working as expected with a new project on MacOS on High Sierra... no issues here.

• MacOS: v10.13.3
• SPFx: v1.4.1
• Node.js: v8.9.2
• NPM: v5.6.0

[Alek-S]

Yeah corporate laptop. Heading home, will try there and on home comp.

[Alek-S]

@nickpape-msft @andrewconnell I found the issue. Port 5432 is the default port value used by PostgreSQL databases, which I had running locally.

Shutting down the PostgreSQL service resolved the issue.

[LouFarho]

@nickpape-msft I still need to set NODE_NO_HTTP2=1 What does one need to update to avoid this?

[andrewconnell]

@LouFarho New or existing project?

Assuming you've updated your project to v1.4.1, I'd suggest deleting your node_modules folder and reinstalling with npm install. Then give it a shot.

If still having issues, post the following in a follow-up:

• contents of package.json in your project
• result of node -v
• version property of the file in node_modules/@microsoft/sp-build-core-tasks/package.json

To answer your question above, this is what changed and the only thing you need to do is update your project to SPFx v1.4.1. I added details on how to do this in my post picking apart v1.4.1.

[LouFarho]

@andrewconnell Thank you sir!
I read your linked article. The npm outdated --global didn't flag the generator. But, I executed npm install @microsoft/generator-sharepoint --global anyway. It did perform an update.
λ npm install @microsoft/generator-sharepoint --global

• @microsoft/[email protected]
  updated 2 packages in 31.084s

I then went to a project folder and executed npm update
I noticed several of the modules in the package.json get updated which was logged in the output.

Running gulp serve executed as desired.

I did notice a bunch of warnings about deprecated packages but I expect that is discussed elsewhere.

[andrewconnell]

When there are a lot of updates like this, I find it's best to blow away node_modules and do a clean install, not an upgrade / update.

Good to hear it's working.

Seems like this can get closed @nickpape-msft / @Alek-S

[nickpape]

Sounds about right @andrewconnell . Generally it is going to be safer to delete/re-install your node_modules folder. This is due to the non-determinism that is inherent to NPM. I'm closing the issue. @LouFarho please open a new one if you continue to experience any issues.

[andrewconnell]

Now that this is closed, I'll pile on...

This is one big reason why I prefer using Yarn over NPM. Yes, NPM created their own lock file, but its got its own issues. With Yarn, you can rest assured you will get the SAME packages every time you run it to rebuild your node_modules folder. PNPM has promise with symlinks and proves there aren't issues following symlinks (that you always seem to run into), but until they iron out those issues, it's Yarn #FTW for me. :)

[waldekmastykarz]

Are the issues with Yarn and React sorted out @andrewconnell?

[andrewconnell]

I am not experiencing any issues with latest versions of both...

[fabianmadurai]

@nickpape-msft @andrewconnell I found the issue. Port 5432 is the default port value used by PostgreSQL databases, which I had running locally.

Shutting down the PostgreSQL service resolved the issue.

@nickpape-msft @andrewconnell I found the issue. Port 5432 is the default port value used by PostgreSQL databases, which I had running locally.

Shutting down the PostgreSQL service resolved the issue.

You sir are a gentleman and a scholar!! This was my problem. thank you so much

[pvijay84]

Using
set NODE_NO_HTTP2=1
gulp serve
Got it to work for me

It work for me. Thank you somuch!!!

[meetKushan]

I had the same issue and changing default port fixed. Since 5432 was already in use.

Change:

[DinethNipuna]

I have the same issue, I can see only a blank sp page , can someone please help me

[MikeFisherEY]

gulp serve does not load the helloworld web part for me either and gets stuck just as the above user. I've been trying to get the hello world webpart working for some time now and it has been a real mess. Following closely the Microsoft guidance on the helloworld webpart does not work. Very frustrating for someone trying to get started with SPFx.

[andrewconnell]

@MikeFisherEY As this issue is closed, can you open a new issue for tracking? Also provide the environment versions (platform, SPFx, Node, NPM, etc) you have installed, screenshot of error, exact step where you're having the issue?

Everything should be working... we can get you unstuck, but a new issue is best place to post it as closed issues generally aren't seen except by those who had commented on them in the past.

[MikeFisherEY]

Thanks for your reply Andrew!

I was just able to get it working by running using Chrome (https://localhost:4321/temp/workbench.html). Guess there was something wrong while running in IE??

Guess I’m now off and running. Really enjoyed your Lightning tools webinar on SPFx development! Thanks for all that you are doing as an SPFx advocate!

Mike Fisher

From: Andrew Connell [mailto:[email protected]]
Sent: Wednesday, February 13, 2019 4:13 PM
To: SharePoint/sp-dev-docs [e-mail]
Cc: Mike D Fisher [e-mail]; Mention [e-mail]
Subject: Re: [SharePoint/sp-dev-docs] SPFX Local workbench not loading (#1256)

@MikeFisherEYhttps://github.com/MikeFisherEY As this issue is closed, can you open a new issue for tracking? Also provide the environment versions (platform, SPFx, Node, NPM, etc) you have installed, screenshot of error, exact step where you're having the issue?

Everything should be working... we can get you unstuck, but a new issue is best place to post it as closed issues generally aren't seen except by those who had commented on them in the past.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SharePoint/sp-dev-docs/issues/1256#issuecomment-463373259, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AtZ956E4j3sln9PIzvwNHS4jAzDEwVF3ks5vNH_GgaJpZM4Rkf9S.

Any tax advice in this e-mail should be considered in the context of the tax services we are providing to you. Preliminary tax advice should not be relied upon and may be insufficient for penalty protection.

---

The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

Notice required by law: This e-mail may constitute an advertisement or solicitation under U.S. law, if its primary purpose is to advertise or promote a commercial product or service. You may choose not to receive advertising and promotional messages from Ernst & Young LLP (except for EY Client Portal and the ey.com website, which track e-mail preferences through a separate process) at this e-mail address by forwarding this message to [email protected]. If you do so, the sender of this message will be notified promptly. Our principal postal address is 5 Times Square, New York, NY 10036. Thank you. Ernst & Young LLP

[andrewconnell]

There are loads of known issues with IE... with the recent news from MSFT's cybersecurity chief coming out against IE11, I wouldn't be surprised if we see something soon about the future of it. My advice to customers: get away from IE & get on a modern evergreen browser. Not just for SPFx, but for life in general.

[utrolig]

I think the output of the gulp task should show port 5432 already in use or something similar.
5432 is maybe not the best default, as that is already the default of PostGresQL?

[andrebarroncas]

I was having the same issue and I saw that PostGresQL was running, so I stopped it and the workbench worked. Thank you!

[Tusharc4227]

I have built a ListView Command Set extension,and i want to do some custom changes init so i need to debug,but i am not able to debug the file as by searching all over i found that my workbench.html file is not generated...i am using node version 10.15.3.
Please give some suggestions

[andrewconnell]

@Tusharc4227 When an issue is closed, people aren't looking at it so it's best to add a new issue. But to address your specific question, you can't debug extensions in the workbench. Ref: https://docs.microsoft.com/en-us/sharepoint/dev/spfx/extensions/get-started/build-a-hello-world-extension#debug-your-application-customizer

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues