plugins/woocommerce/tests/e2e-pw/utils/payments-settings.ts (1)

14-15: Use console.error for error output.

Errors should go to stderr via console.error rather than console.log so they're distinguishable in CI logs.

Suggested fix

 	} catch ( error ) {
-		console.log( error );
+		console.error( error );
 	}

plugins/woocommerce/tests/e2e-pw/utils/coming-soon.ts (1)

18-22: Consider re-throwing after logging to surface setup failures.

The catch block swallows the error, so callers have no signal that the "coming soon" option wasn't set. A silently failed precondition can cause misleading downstream test failures that are hard to diagnose.

♻️ Suggested improvement

 	try {
 		await setOption( request, baseURL, 'woocommerce_coming_soon', enabled );
 	} catch ( error ) {
 		console.log( error );
+		throw error;
 	}

plugins/woocommerce/tests/e2e-pw/utils/variable-products.ts (1)

190-196: combine inner function parameters have implicit any types.

runningList and nextAttribute are untyped function parameters, which will be implicitly any under strict TypeScript. This is pre-existing complexity from the JS version, but since the PR adds type annotations to all other function parameters, these stand out. Consider typing them in a follow-up if noImplicitAny is enabled or planned.

plugins/woocommerce/tests/e2e-pw/utils/cli.ts (1)

9-15: Shell command injection risk via unsanitized command parameter.

exec spawns a shell, and command is interpolated directly into the string. Any shell metacharacters in command (;, |, $(), etc.) would be interpreted. While callers are internal test code today, the coding guidelines require guarding against unexpected inputs.

A safer alternative would be execFile (no shell) or at minimum a basic validation/allowlist on the command string. Since this is test-only utility code, this is low-priority but worth being aware of.

plugins/woocommerce/tests/e2e-pw/utils/variable-products.ts (2)

26-26: Module-level mutable productIds — acceptable for test utilities but worth a note.

The shared mutable array accumulates IDs across calls, and deleteProductsAddedByTests clears them via the API but never resets the array itself. If tests call deleteProductsAddedByTests and then create more products, the array will still contain the old (now-deleted) IDs alongside the new ones, causing a redundant (or failing) delete on the next cleanup call. This is likely fine in practice given test isolation, just calling it out.

Also applies to: 119-131, 137-139

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@plugins/woocommerce/tests/e2e-pw/utils/variable-products.ts` at line 26, The
module-level mutable array productIds retains deleted IDs causing
redundant/failing cleanup; update the cleanup routine deleteProductsAddedByTests
(and any other functions that clear via API) to also reset the in-memory array
(e.g., productIds.length = 0 or assign a new empty array) after successful
deletion, and ensure any functions that push to productIds (the helpers that
create test products) continue to push fresh IDs; this guarantees productIds
doesn't accumulate stale IDs across test runs.

---

189-228: The combine helper has an inconsistent return shape when attributes has only one element.

When attributes.length === 1, generateVariationsFromAttributes returns string[] (the raw options), but with 2+ attributes it returns string[][]. The declared type of allVariations (string[] | string[][]) accurately reflects this, but callers must handle both shapes — which is error-prone.

This is pre-existing behavior from the JS version, so not blocking, but worth noting for a future cleanup: you could normalize the single-attribute case to return string[][] (e.g., attributes[0].options.map(o => [o])) so the return type is always string[][].

Also, attributes[0].options on line 220 will throw if called with an empty array. A guard would make this safer, though admittedly this is a test utility with controlled inputs.

♻️ Optional: normalize the initial value so the return type is always `string[][]`

-	let allVariations: string[] | string[][] = attributes[ 0 ].options;
+	if ( attributes.length === 0 ) {
+		return [];
+	}
+
+	let allVariations: string[][] = attributes[ 0 ].options.map( ( o ) => [ o ] );
 
 	for ( let i = 1; i < attributes.length; i++ ) {
 		const nextAttribute = attributes[ i ].options;
 
 		allVariations = combine( allVariations, nextAttribute );
 	}

This would also let you simplify combine to always accept string[][], removing the union type and the normalization branch.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@plugins/woocommerce/tests/e2e-pw/utils/variable-products.ts` around lines 189
- 228, generateVariationsFromAttributes returns inconsistent shapes: when
attributes.length === 1 it returns string[] (raw options) but for 2+ attributes
it returns string[][]; also attributes[0].options will throw if attributes is
empty. Fix by normalizing the initial value and combine signature: convert the
single-attribute case into an array-of-arrays (e.g. map options to [o]) so
allVariations is always string[][], simplify combine to accept string[][] and
always return string[][], and add a guard at the start of
generateVariationsFromAttributes to handle or early-return when attributes is
empty.