[Playground CLI] Add enableCookieStore argument to runCLI

[bgrgicak]

Motivation for the change, related issues

In a recent PR, we disabled the cookie store for Playground CLI. This way, browsers can control cookies when running WordPress using the Playground CLI.

But when using runCLI for testing, the cookie store can be useful because it allows tests to store login cookies between requests.
This PR proposes an enableCookieStore argument for the runCLI function, enabling users to activate the cookie store.

I considered adding an argument to the CLI, but I can't think of any use for enabling cookie stores when running it from the terminal.

Implementation details

runCLI now accepts a enableCookieStore argument. If the argument is set to true, the default cookie store will be used inside the PHPRequestHandler. Otherwise, the cookie store will be disabled.

Testing Instructions (or ideally a Blueprint)

• CI

[adamziel]

What would be an example of a use-case?

[bgrgicak]

What would be an example of a use-case?

Writing integration tests for Playground. For example this test file used to work before we disabled the cookie store.

Without a cookie store, I can't login the user with integration tests.

[adamziel]

Couldn't we use a test client that supports cookie headers instead? Cookie store won't work for tests involving more than one login session.

[bgrgicak]

Couldn't we use a test client that supports cookie headers instead? Cookie store won't work for tests involving more than one login session.

Do you mean like a client specialized for testing, e.g., instead of runCLI, runTester?

I considered building a testing library, but it would still mostly be the same as runCLI with only a couple of extra arguments. I'm not sure if it's worth adding another client and maintaining it if it's really close to what we already have.

[bgrgicak]

Could you maybe explain what your concern is with expanding runCLI to cover this use case?

[adamziel]

My concern is processing cookies differently in the test suite and outside of the test suite. How would we know if the tests are reliable? Cookies are typically handled by the client, not by the server. Multiple clients can co-exist with different sets of cookies. The client may also support domain– and path– specific cookies, when the server doesn't always see the domain or the path in the same way as the client.

Do you mean like a client specialized for testing, e.g., instead of runCLI, runTester?

I just mean a cookie-aware middleware, e.g. similar to this:

const cliServer = await runCLI({
	command: 'server',
});
const testClient = cookieAwareClient( cliServer.requestHandler );
const response = await testClient.request({
	url: '/wp-login.php',
	method: 'POST',
	// ... login data ...
});
// testClient processes response cookies, saves them, and adds them to request headers
// for subsequent requests

cookieAwareClient could be a simple wrapper similar to HttpCookieStore. It would parse the set-cookie header and add the appropriate Cookie header to every request. Then we could get rid of the HttpCookieStore entirely.

[bgrgicak]

Thanks, this context helps me a lot!

What about this: a4e17ee?

Instead of the Playground CLI setting the Cookie store, the PHPRequestHandler can have a setCookieStore method, which would allow us to set or disable the cookie store once we obtain a request handler object.

[bgrgicak]

Not needed, just demonstrates how to use the setCookieStore method.

[adamziel]

Add a setCookieStore method to the PHPRequestHandler

Note it must be separate from the request handler. Otherwise we can't write a test where two users send alternating requests.

[bgrgicak]

@adamziel and I chatted about this and concluded that there's no real need for a cookie-enabled client in Playground besides my use case.

Because I already use fetch to make requests instead of the PHPRequestHandler, it will be best for me to use a library like fetch-cookie for cookie storage.