Unable to serve react-content-query-webpart with gulp serve --nobrowser #563
Comments
|
@lworkman You will have to work with the WebPart in a real SharePoint site as I didn't create a mocked version of the service (responsible for all the REST interactions) to be used when running in a workbench context. That basically mean the WebPart will most likely throw errors in the workbench as soon as you'll open the toolpane because it will try to fetch information from SharePoint for getting the available sites, webs, list, fields etc... Simply follow this article the use the WebPart in "local mode" but deployed in a real SPO site. Basically what you have to do is the following :
Using the package-solution command without the --ship flag basically ignores the provided CDN url and makes sure to point to the localhost adress instead, allowing you to update the code locally and see the changes directly in SPO. On another note, I am not totally sure why it complains about a manifests.json error, did you try to "gulp" the project before trying to serve it? Anyway even if it did not throw this error like I said you would end up with many other errors because the code isn't mocked for a workbench context right now. It would be a nice contribution if you have time though, adding a small check before initializing the service that would make sure to initialize a mocked version of the service when detecting a workbench context : if (Environment.type === EnvironmentType.Local) {
this.ContentQueryService = new MockedContentQueryService(...);
}
else {
this.ContentQueryService = new ContentQueryService(...);
}Let me know if that helps 👍 |
|
@lworkman any update in the issue? I was curious about the
And I could add my WebPart to the workbench just fine, like I expected there was some errors once I opened the toolpane because as I explained earlier the REST calls aren't mocked for the workbench context, but otherwise everything works fine for me : |
|
Thanks for the response @spplante, I am mainly worried about the Just from looking at my system, it appears to be an issue with the version of the framework included in the main repository. The I don't know if this is because of the node issues older versions of the framework have, or something else entirely. If you have the time, I suggest updating the main repository to the |
|
@lworkman the zip included at the root of the project is this very same project updated to 1.4.1. The reason why the main project uses 1.1.0 is simple : It is the version supported by SharePoint 2016 onprem. To have a WebPart compatible with SharePoint 2016, I have no choice but to leave it at 1.1.0. Stil today when using the Yeoman generator and selecting the "SP2016 & SPO" compatibility option, it uses 1.1.0. The downside with 1.1.0 is the fact that you must specify a CDN url where the compiled binaries are stored, something the 1.4.1 version fixed by allowing the sources to be included directly in the .sppkg. So if you are only using the WebPart in SPO, I strongly recommend you to use the 1.4.1 version. I also try to keep both versions in sync so whenever I make a change to the main version I do update the .zip file as well. That being said, I literally just tried the main package (1.1.0) and I have no manifest error at all, can you confirm that there is no error while the project is gulping? Can you see the generated |
|
@spplante Ahh, I understand. We might have to leave it at me using the .zip, as I would prefer not to have to deal with the CDNs. I do know that SPFX versions prior to |
|
Hmm yes I remember that NO_NODE_HTTP2 fix I think I had to do this at home because I was working with node v8, I just checked at work right now I am using node v7.4.0, that might be the reason why it works for me. I will try it out at home tonight to see if it works but I am the one who did the last check-in on the project so I am pretty sure it does work with node v8 but I remember having to follow this resolution in order to make it work : If you look in the comments it does say "Aaaaaaannnnd this is resolved in the Yeoman Generator v1.4.1. Upgrade to that version for no workaround to use Node.js v8 LTS." which might explain why you don't have the problem with the 1.4.1. I am pretty sure it doesn't have to do anything with the webpart but most likely running SPFX 1.1.0 with node v8, I will check if I am runing v8 at home tonight and report back. Edit : Can you post a screenshot of the exact error shown in the UI? |
|
This is what I get when I try to open the workbench: This is what I get when I try to open a SPO workbench: And my terminal doesn't report any connection: |
|
Hmm it looks like an HTTPS problem, if you look around this problem appears in a lot of different issues, with different fixes depending on the situation.
|
|
Ahh @spplante, turns out it IS the pre- Not sure if you want to do anything with this information. Locally, I was in the habit of adding a Anyways, thanks for your help! |
|
Ah! Good news :) I am also using node v8 but since it is not totally supported by SPFx I feel like it should stay as-is until it's officially supported, meanwhile people can use the documented fix like you mentionned. Thanks! |
Category
Authors
@spplante
Expected or Desired Behavior
npm installgulp serve --nobrowserObserved Behavior
I'm trying to extend the
react-content-query-webpartexample, but I'm unable to serve it locally for development. When I serve it throughgulp serve, I can't access my local workbench to load it. As well, if I try to load it through an SPO workbench, I get an error that themanifests.jsonfile can't be found.I've even tried setting a
GETrequest with postman against themanifests.jsonURL, which returns nothing, even though it's worked in the past with other webparts.If I extract out
content-query-webpart-1.4.1.zipand go into that, I have no problem running the webpart locally. However, I would prefer to fork from the main repo so I rebase when necessary.Steps to Reproduce
gulp serve --nobrowsermanifests.jsonnot found error.The text was updated successfully, but these errors were encountered: