Sp-dev-docs: Not able to run app in local workbench after upgrading spfx to 1.6.0
lipalath-ms
All 6 comments
Or you can execute gulp serve, which will run correctly, but which will open a browser window that you can close.
waldekmastykarz
on 10 Sep 2018
Looking into this. Thanks for the heads up.
patmill
on 11 Sep 2018
OK, so there was a change in how some of the code is laid down. To get this to work properly with --nobrowser, navigate to https://localhost:5432/workbench . It copies all of the packages, and redirects to :4321/temp/workbench.html
Looking further, as @waldekmastykarz mentioned in the other thread, this was actually introduced back in 1.5.0. I guess the intersection of devs using --nobrowser and the localbench is small.
We have code that executes at runtime to create the workbench file for the current configuration. That happens when you hit the initialPage, which is "initialPage": "https://localhost:5432/workbench",
We do that for you in gulp serve, and when you use --nobrowser, you'll need to hit that page yourself.
patmill
on 11 Sep 2018
@licypal are you trying to set the breakpoint in the browser or in the code editor?
waldekmastykarz
on 11 Sep 2018
@licypal are you following the steps as described in the docs at https://docs.microsoft.com/en-us/sharepoint/dev/spfx/debug-in-vscode?
waldekmastykarz
on 11 Sep 2018
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
msft-github-bot
on 26 Jan 2020
Related issues
thechriskent
路
3Comments
waldekmastykarz
路
3Comments
StfBauer
路
3Comments
SteIvanov
路
3Comments
Ralms
路
3Comments
Most helpful comment
OK, so there was a change in how some of the code is laid down. To get this to work properly with --nobrowser, navigate to https://localhost:5432/workbench . It copies all of the packages, and redirects to :4321/temp/workbench.html
Looking further, as @waldekmastykarz mentioned in the other thread, this was actually introduced back in 1.5.0. I guess the intersection of devs using --nobrowser and the localbench is small.
We have code that executes at runtime to create the workbench file for the current configuration. That happens when you hit the initialPage, which is
"initialPage": "https://localhost:5432/workbench",We do that for you in gulp serve, and when you use --nobrowser, you'll need to hit that page yourself.