Feature Request: Expand Node.js Bindings to Match Python Coverage

Feature Request: Expand Node.js Bindings to Match Python Coverage

Summary

The Node.js bindings for rustwright currently expose only ~11 methods (launch, newPage, goto, click, fill, title, textContent, evaluate, screenshot, close), while the Python bindings have 96% coverage (515/536 methods). This makes rustwright unusable for TypeScript/Node.js test suites that require features like storage_state, BrowserContext, Locator, and @playwright/test fixtures.

Background

I'm evaluating rustwright as a potential replacement for Playwright in a production TypeScript/Node.js project using modern web frameworks. The Python bindings are production-grade at 96% parity, but the Node.js bindings are too limited for real-world E2E testing.

Project Context

• Stack: TypeScript/Node.js, Astro 5, Vue 3, Better Auth, Docker PostgreSQL
• Test suite: 29 Playwright spec files using @playwright/test runner
• Current Playwright usage: storage_state for auth persistence, BrowserContext for test isolation, Locator for assertions, fixtures for setup/teardown
• Goal: Replace Playwright driver with rustwright to reduce memory (70% less) and improve startup time (2.55x faster)

Current Node.js Bindings

Available methods (~11):

launch, newPage, goto, click, fill, title, textContent, evaluate, screenshot, close (×2 variants)

Missing features critical for production E2E testing:

Feature	Node.js Status	Python Status	Impact
storage_state (save/restore)	❌ Not bridged	✅ Available	Blocks auth persistence (session cookies/tokens)
BrowserContext	❌ Not bridged	✅ 30/30 methods	Blocks test isolation (29 spec files require this)
Locator (first-class)	❌ Not bridged	✅ 60/62 methods	Blocks assertions (page.locator(), expect().toBeVisible(), etc.)
@playwright/test fixtures	❌ Not supported	✅ pytest fixtures	Blocks test runner (cannot use existing test infrastructure)
Event waiters (waitForResponse, etc.)	❌ Not bridged	✅ Available	Blocks E2E flows (wait for API responses, network idle, etc.)
Route/network interception	❌ Not bridged	✅ Available	Blocks API mocking (mock backend responses in tests)

Use Case

Authentication Flow (Session Management)

// This is what we need to do in production test suites:
test('user can access dashboard after login', async ({ page, context }) => {
  // Save auth state after login
  await context.storageState({ path: 'auth.json' });
  
  // Restore auth state in subsequent tests
  const context = await browser.newContext({ storageState: 'auth.json' });
  const page = await context.newPage();
  
  // Navigate to protected route
  await page.goto('/dashboard');
  
  // Assert authenticated state
  await expect(page.locator('[data-testid="user-menu"]')).toBeVisible();
});

Current Node.js limitation: Cannot save/restore storage_state, so every test would need to re-authenticate (slow, flaky).

Test Isolation

// Each test needs isolated context:
test.describe('User management', () => {
  test('create user', async ({ page }) => {
    // Independent context, cookies don't leak between tests
    await page.goto('/users');
    await page.click('[data-testid="create-user"]');
    // ...
  });
  
  test('delete user', async ({ page }) => {
    // Fresh context, no state from previous test
    await page.goto('/users');
    // ...
  });
});

Current Node.js limitation: No BrowserContext means no test isolation. Tests would share cookies/storage, causing flakiness.

Locator Assertions

// Modern Playwright tests use Locator extensively:
await expect(page.locator('.success-message')).toBeVisible();
await expect(page.getByTestId('user-table')).toHaveCount(10);
await page.locator('[data-testid="submit"]').click();

Current Node.js limitation: No Locator API, only basic click/fill with selectors. Cannot use expect() assertions.

Proposed Solution

Expand Node.js bindings to cover the same API surface as Python:

1. Priority 1 (Critical for E2E testing):

   • BrowserContext (create, close, cookies, storageState)
   • Locator (query, click, fill, expect assertions)
   • storageState (save/restore)

2. Priority 2 (Important for production use):

   • Event waiters (waitForResponse, waitForSelector, waitForLoadState)
   • Route/network interception (page.route(), request.continue())
   • @playwright/test integration (fixtures, reporters)

3. Priority 3 (Nice to have):

   • Tracing/screenshots with full options
   • Frame/iframe support
   • Multi-tab support

Workaround

Currently, the only workaround is to use Python bindings (96% coverage), but this requires:

• Separate test suite in Python (duplicating TypeScript tests)
• Additional infrastructure (Python virtualenv, pytest, etc.)
• More coordination (maintaining 2 test suites)

This defeats the purpose of rustwright as a drop-in replacement for TypeScript/Node.js projects.

Environment

• rustwright version: 0.1.1 (npm)
• Node.js version: 20.x
• TypeScript version: 5.x
• OS: Linux (Ubuntu 22.04)

Additional Context

The Python bindings are excellent (96% coverage, production-grade). The Node.js bindings appear to be an early alpha within an alpha. Expanding them would make rustwright viable for the large TypeScript/Node.js ecosystem, not just Python projects.

I'm willing to test early builds, provide feedback, and contribute documentation once the Node.js bindings expand.

---

Labels: enhancement, nodejs-bindings, api-parity
Milestone: Post-v1.0 (when behavioral parity stabilizes)

The issue names no files, tests, or entry points. Start by mapping the existing Node.js bindings against the Python API and split the broad parity request into a scoped milestone, with completion defined by the selected BrowserContext, Locator, storageState, or waiter behavior and corresponding Node.js coverage.