Use actual WordPress in Playground tests

[eliot-akira]

From discussion in #427 comment.

wp-now could be useful for server-side tests to make use of a full WordPress environment

A difficulty: if wp-now imports from the Playground package being tested, the tests cannot import from wp-now because it results in a circular dependency.

When I imported the package from the test, I got an error from nx or vitest, "Could not execute command because the task graph has a circular dependency" - because that package imports blueprints.

That’s a challenging one. Perhaps building wp-now to a single bundle and then using that to run Blueprints tests would solve it here. This is the second time this comes up today- the first time was in #434

Found a documentation page about this in the nx repository.

Resolving Circular Dependencies

Strategies recommended:

• Make more granular projects with less inter-dependence
• Or merge such projects into a single project that is free to depend on itself
• Or separate the extra logic into a new project that is shared between the projects which desire this logic

[adamziel]

@eliot-akira I’m thinking of using the WordPress data modules that already come with the repository. Perhaps a @wp-playground/wordpress package would make sense for those? Not sure yet.

About wp-now specifically, I will propose a vision and a crisp scope for the core Playground repo in a few days. The idea is to stabilize the project, have predictable expectations, and keep it focused on the framework. This involves moving consumer apps to separate repos so let’s put the wp-now part of this issue on hold for now.

[adamziel]

With wp-now moved to the playground-tools repo, let's find a way to resolve this using the building blocks available in this repository.

[adamziel]

There's a precedent of this in sql.spec.ts:

wordpress-playground/packages/playground/sync/src/test/sql.spec.ts

Lines 111 to 120 in 39a7df2

	async function getWordPressDataModule() {
	const wpData = readFileSync(__dirname + '/wp-6.3.data');
	const wpDataArrayBuffer = wpData.buffer.slice(
	wpData.byteOffset,
	wpData.byteOffset + wpData.byteLength
	);
	shimXHR(wpDataArrayBuffer);
	// @ts-ignore
	return await import('./wp-6.3.js');
	}

We should find a way to generalize this to all packages. I wonder if Blueprints should do that internally as Playground depends on Blueprints. If Blueprints also depended on Playground, that would be a circular dependency. We should be fine to just copy WordPress 6.3 data module to Blueprints for now and then reflect on the internal dependency graph. Perhaps introducing a playground-test-utils package would solve this?

[eliot-akira]

Perhaps introducing a playground-test-utils package would solve this?

That sounds like a good solution, it aligns with one of the suggestions in the nx repo's Wiki (here).

Another common case is that the consumer of a project has some extra logic that is desirable from producing libraries. When this extra logic is consumed by a producing project, it creates a circular dependency. The solution to this case is to separate the extra logic in the producing project into a new project that is shared between the projects which desire this logic.

---

We should be fine to just copy WordPress 6.3 data module to Blueprints for now

I saw that the new package playground/sync bundles its own copy of wp-6.3.{js,wasm} in src/test. Wouldn't it be better to use those same files from the php-wasm package (in node/public) since they're already checked into the repo?

[adamziel]

With Node.js WordPress support initially merged in #837 and a battery of WordPress-related unit tests added in #982, this issue seems to be solved.

Here's a unit test covering the activateTheme Blueprint step by interacting with an actual WordPress module sourced from the same .zip file as used by playground.wordpress.net website (the .data modules are gone since #978):

https://github.com/WordPress/wordpress-playground/blob/trunk/packages/playground/blueprints/src/lib/steps/activate-theme.spec.ts