Load client from playground.wordpress.net instead of @wp-playground/client

[ashfame]

@adamziel made the suggestion to use the client from playground.wordpress.net itself to have a version that’s always synchronized with the Playground version

[psrpinto]

I'm not sure I understand how this would work, could you clarify how we would use the client from playground.wordpress.net?

[ashfame]

Like this:

<iframe id="wp" style="width: 100%; height: 700px; border: 1px solid #000;"></iframe>

<script type="module">
    import { startPlaygroundWeb } from 'https://playground.wordpress.net/client/index.js';

try {
    const mountDescriptor = {
        device: {
            type: 'opfs',
            path: '/try-wp-zz',
        },
        mountpoint: '/wordpress',
    };

    const isWordPressInstalled = confirm('Is WordPress installed? Ok=yes; Cancel=no;');
	console.log( isWordPressInstalled ? 'WP: Already Installed' : 'WP: Not Installed' );

    const client = await startPlaygroundWeb({
        iframe: document.getElementById('wp'),
        remoteUrl: `https://playground.wordpress.net/remote.html`,
        mounts: [mountDescriptor],
        shouldInstallWordPress: ! isWordPressInstalled,
    });
    await client.isReady();
    window.pgclient = client;
} catch (error) {
    console.error("pg client", error);
}
</script>

[psrpinto]

Thanks for clarifying. This might might make it a little better, but I see some invonveniences:

• There would be no types
• The APIs can still change and our code would still need to be adapted. For example, if startPlaygroundWeb()'s API changes.
• We can't leverage debugging tools like git bisect because we can never be sure if something is broken due to changes in playground.wordpress.net.

I think ultimately, the best solution would be to package playground into the extension. If that's not possible, for reasons outside our control (e.g. browser limitations), another possibility would be for playground.wordpress.net to provide multiple versions, e.g. https://playground.wordpress.net/v0.1.2.

[ashfame]

Agree! Or we can host our own instance try-wp-playground.wordpress.net & control when to update it.

[adamziel]

The APIs can still change and our code would still need to be adapted. For example, if startPlaygroundWeb()'s API changes.

I want to avoid breaking changes in startPlaygroundWeb as it would affect all the apps integrating Playground. However, even assuming breaking changes, it doesn't matter where the client comes from as remote.html would also be affected.

For non-breaking changes, loading the client from playground.wordpress.net would actually keep the browser extension working – the client would be auto-updated in the same deployment as remote.html.

We can't leverage debugging tools like git bisect because we can never be sure if something is broken due to changes in playground.wordpress.net.

Isn't that true for any technique of importing the client?

There would be no types

Isn't there a way to configure TypeScript to still get types? Like an import map in tsconfig.json?

Agree! Or we can host our own instance try-wp-playground.wordpress.net & control when to update it.

Yup, that would work too. If you host it on the atomic platform, you should be able to just fork the Playground repo and reuse the same deployment scripts.