[Blueprints] Use the local worker in Builder during development mode #2495
Conversation
There was a problem hiding this comment.
Hi @mho22, thank you for working on this. This issue has bothered me for a while, but I haven't taken the time to fix it.
I left some questions and suggestions below, but this looks like a good thing for us to do.
| @@ -215,6 +215,8 @@ const validRemoteOrigins = [ | |||
| 'https://localhost', | |||
| 'http://127.0.0.1', | |||
| 'https://127.0.0.1', | |||
| 'http://127.0.0.1:4400', | |||
| 'http://localhost:4400', | |||
There was a problem hiding this comment.
Is there any downside to using
import { remoteDevServerHost, remoteDevServerPort } from '../../build-config';
in this module and defining these string using those imports?
There was a problem hiding this comment.
No, you're right I should use these configs instead. On it.
| target: | ||
| mode === 'production' | ||
| ? 'https://playground.wordpress.net' | ||
| : `http://${remoteDevServerHost}:${remoteDevServerPort}`, |
There was a problem hiding this comment.
IIRC, the purpose of this bit is to forward requests to playground.wordpress.net/plugin-proxy.php when a plugin-proxy.php request is received by the the dev server. The plugin-proxy.php script requires PHP and a GH_TOKEN environment var, so I think maybe we want to keep forwarding such requests to playground.wordpress.net where there is both a PHP server and that secret defined.
| import.meta.env.MODE === 'production' | ||
| ? `https://playground.wordpress.net/plugin-proxy.php?${proxyParams}` | ||
| : `http://${remoteDevServerHost}:${remoteDevServerPort}/plugin-proxy.php?${proxyParams}` |
There was a problem hiding this comment.
Could we conditionally define the target origin once in this module and replace these ternaries with a single template str? For example:
| import.meta.env.MODE === 'production' | |
| ? `https://playground.wordpress.net/plugin-proxy.php?${proxyParams}` | |
| : `http://${remoteDevServerHost}:${remoteDevServerPort}/plugin-proxy.php?${proxyParams}` | |
| `${playgroundServerOrigin}/plugin-proxy.php?${proxyParams}` |
There was a problem hiding this comment.
On a related note, what if we default to the current origin when in production so both of the following could work?
https://playground.wordpress.net/builder/builder.html
https://my.favorite.self.hosted.playground.domain/builder/builder.html
There was a problem hiding this comment.
done. It is way more readable!
|
@brandonpayton Thank you for your review! I added the corrections you suggested. |
Motivation for the change, related issues
In order to find a solution to issue #2466. I struggled to go through the
worker-threadrun on port 4400 as the one used in the builder is theplayground.wordpress.netone when runningnpm run dev.Implementation details
If
import.meta.env.MODE === 'productionthen use the remote worker, else use the local one.Additionally, due to complex caching, other steps should be taken into account to get a fresh worker during page refresh. Explained below.
I didn't modify the following files :
And possible errors can occur in these tests :
Testing Instructions
Add a test log inside the
bootmethod inworker-thread.ts.Run
npm run devGo to http://127.0.0.1:5400/website-server/builder/builder.html
Unregister the http://127.0.0.1:4400 service worker.
Delete the
playground-cache-inCacheStoragedata in theCacheStoragesection inApplicationtab from the browser developer tools.Refresh page.
You should see the log.
bootmethod inworker-thread.tsand reproduce the steps 3 to 5.You should see the modified log.
Extra steps if the service worker stops running unexpectedly :
Bypass for networkin theService Workersection in theApplicationtab from the browser developer tools and unregister the service worker fromhttp://127.0.0.1:4400.Bypass for networkin theService Workersection in theApplicationtab from the browser developer tools and do a hard refresh the page again.