Package libsecret-1 was not found in the pkg-config search path. about docker-spfx HOT 11 CLOSED

yeah that's weird I tried it a couple of times before I raised the error and I got the same issue. I tried again yesterday and no error. however I got a different issue this time

on checking the notes I thought I might need to make the changes t the SPWebBuildRig.js but on my file I don't have the information to change in it

I am experiencing this exact same issue as well with the 1.12.1 release. It appears that the generated manifest correctly uses https://localhost:4321 in all of the loaderConfig/internalModuleBaseUrls sections except the very last one, which happens to include all of the scriptResources for "hello-world-web-part." Its "internalModuleBaseUrls" array contains "https://0.0.0.0:4321/dist/" and so the workbench attempts to load "hello-world-web-part.js" from this URL, which fails. If I manually go to https://localhost:4321/dist/hello-world-web-part.js outside the workbench, the script loads just fine.

`[SPLoaderError.loadComponentError]:
Failed to load component "b0605d1f-279b-4de4-8f73-66b694df270c" (HelloWorldWebPart). Original error: Failed to load URL 'https://0.0.0.0:4321/dist/HelloWorldWebPartStrings_en-us.js' for resource 'HelloWorldWebPartStrings' in component 'b0605d1f-279b-4de4-8f73-66b694df270c' (HelloWorldWebPart). There was a network problem. This may be a problem with a HTTPS certificate. Make sure you have the right certificate.

INNERERROR:
Failed to load URL 'https://0.0.0.0:4321/dist/HelloWorldWebPartStrings_en-us.js' for resource 'HelloWorldWebPartStrings' in component 'b0605d1f-279b-4de4-8f73-66b694df270c' (HelloWorldWebPart). There was a network problem. This may be a problem with a HTTPS certificate. Make sure you have the right certificate.
CALLSTACK:
Error
at SPLoaderError.SPError [as constructor] (https://localhost:4321/temp/workbench-packages/@microsoft_sp-webpart-workbench/local-workbench/sp-webpart-workbench-assembly_en-us.js:38476:23)
at new SPLoaderError (https://localhost:4321/temp/workbench-packages/@microsoft_sp-webpart-workbench/local-workbench/sp-webpart-workbench-assembly_en-us.js:52330:28)
at Function.ff4n.ErrorBuilder.buildErrorWithVerboseLog (https://localhost:4321/temp/workbench-packages/@microsoft_sp-webpart-workbench/local-workbench/sp-webpart-workbench-assembly_en-us.js:54879:21)
at Function.ff4n.ErrorBuilder.buildLoadComponentError (https://localhost:4321/temp/workbench-packages/@microsoft_sp-webpart-workbench/local-workbench/sp-webpart-workbench-assembly_en-us.js:54748:21)
at https://localhost:4321/temp/workbench-packages/@microsoft_sp-webpart-workbench/local-workbench/chunk.systemjs-component-loader_en-us.js:1025:75`

Since there is no relevant section to change in SPWebBuildRig.js like there was with the 1.11 release, it seems like we're now missing a way to have the gulp bundle task write the proper debugBasePath into this one URL within the manifest.

from docker-spfx.

Thanks for such a thorough notes @dannyjessee. It would be good to share this with the SPFx team by creating an issue at https://github.com/SharePoint/sp-dev-docs/issues and explaining how it's blocking you. Hopefully they'll be able to address this in the future versions.

from docker-spfx.

Is there still an issue after applying the workarounds described in Readme, @dannyjessee, @DavidF-Beam?

No further issues here. I just closed the original issue I submitted about this last year. Thanks!

from docker-spfx.

Which version of the image are you using? Do you have some additional information about how I could reproduce this issue?

from docker-spfx.

Hey, sure no problem.

This is my first run of the container after finding it online. its using the latest image. I've basically downloaded the image and started the yo creation. I've not made any changes and I'm basically following through the readme to get it setup to start testing on.

during the yo @microsoft/sharepoint command I start getting warning about depreciated versions which ends with the error below. it starts after thnpm audit fix commands

> [email protected] build /usr/app/spfx/node_modules/keytar
> node-gyp rebuild

Encase you need the information my docker version is v20.10.6 and windows is 1909 on WSL2
Any help you could give me would be great, as using docker for this kind of development seems like a no brainer

Thanks David

from docker-spfx.

I wonder if that might've been a network glitch. I tried reproducing it, but it's working as expected for me. Would you mind giving it another try?

from docker-spfx.

yeah that's weird I tried it a couple of times before I raised the error and I got the same issue. I tried again yesterday and no error. however I got a different issue this time

on checking the notes I thought I might need to make the changes t the SPWebBuildRig.js but on my file I don't have the information to change in it

from docker-spfx.

Have you adjusted the hostname as mentioned in the docs @ https://github.com/waldekmastykarz/docker-spfx#cant-access-workbench-and-bundles-in-sharepoint-framework-160?

from docker-spfx.

hey,

Yeah I made that change without it I couldnt even connect to the workbench

I did notice an error on the gulp serve which I don't know if this happens all the time or if its unrelated.

from docker-spfx.

If I'm not mistaken, this is expected, because there is no browser installed inside the Docker container so when SPFx is trying to open the workbench it fails.

Have you tried to open the failing https://0.0.0.0:4321/... URL in the browser to see if you can access it?

from docker-spfx.

Is there still an issue after applying the workarounds described in Readme, @dannyjessee, @DavidF-Beam?

from docker-spfx.