vitest-browser-qwik 0.0.3 → 0.0.4

package/README.md

@@ -52,17 +52,21 @@ test('renders counter with SSR', async () => {
 ### Hook Testing Example
 
 ```tsx
-import { renderHook } from 'vitest-browser-qwik'
-import { useSignal } from '@builder.io/qwik'
+import { useSignal } from "@builder.io/qwik";
+import { expect, test } from "vitest";
+import { renderHook } from "vitest-browser-qwik";
+import { useCounter } from "./fixtures/useCounter";
 
-test('tests custom hook', async () => {
-  const { result } = await renderHook(() => useCounter({
-    countSignal: useSignal(0),
-  }));
-  
-  expect(result.count.value).toBe(0);
-  result.increment();
-  expect(result.count.value).toBe(1);
+test("should increment counter", async () => {
+	const { result } = await renderHook(() =>
+		useCounter({ countSignal: useSignal(0) }),
+	);
+
+	console.log("RESULT", result);
+
+	await result.increment$();
+
+	expect(result.count.value).toBe(1);
 });
 ```
 
@@ -73,7 +77,7 @@ Both `render` and `renderSSR` provide the same testing interface, but work diffe
 - **`render` (CSR)**: Renders components in the browser context
 - **`renderSSR` (SSR)**: Executes components in a Node.js context to generate server-side HTML, then provides that HTML for testing
 
-The SSR approach is unique because it executes your components in a different context than your test files, simulating real server-side rendering behavior.
+The SSR approach is unique because it executes your components in a different context than your test files, real server-side rendering behavior in Vitest.
 
 ## Render Options
 
@@ -109,6 +113,12 @@ test('renders with custom container', async () => {
 - **SSR Context**: `renderSSR` executes components in a Node.js context separate from your test files, providing true server-side rendering simulation
 - **Same Interface**: Both CSR and SSR provide the same testing interface, making it easy to test both rendering modes
 
+## Limitations
+
+- For `renderSSR` you must always import the component from another file, local components are not supported. This is because this would require importing the vitest context, or moving local components into separate files dynamically, which involves a lot of unwanted complexity.
+
+- In the vitest config there is a hardcoded value for whether or not browser mode is headless. This is because when relying on environment variables, it seems there is an additional cost in the vitest core side that introduces potential race conditions.
+
 ## Contributing
 
 Feel free to open issues and pull requests. All contributions are welcome!

package/dist/chunk-51aI8Tpl.js

@@ -0,0 +1,33 @@
+//#region rolldown:runtime
+var __create = Object.create;
+var __defProp = Object.defineProperty;
+var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
+var __getOwnPropNames = Object.getOwnPropertyNames;
+var __getProtoOf = Object.getPrototypeOf;
+var __hasOwnProp = Object.prototype.hasOwnProperty;
+var __commonJS = (cb, mod) => function() {
+	return mod || (0, cb[__getOwnPropNames(cb)[0]])((mod = { exports: {} }).exports, mod), mod.exports;
+};
+var __export = (target, all) => {
+	for (var name in all) __defProp(target, name, {
+		get: all[name],
+		enumerable: true
+	});
+};
+var __copyProps = (to, from, except, desc) => {
+	if (from && typeof from === "object" || typeof from === "function") for (var keys = __getOwnPropNames(from), i = 0, n = keys.length, key; i < n; i++) {
+		key = keys[i];
+		if (!__hasOwnProp.call(to, key) && key !== except) __defProp(to, key, {
+			get: ((k) => from[k]).bind(null, key),
+			enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable
+		});
+	}
+	return to;
+};
+var __toESM = (mod, isNodeMode, target) => (target = mod != null ? __create(__getProtoOf(mod)) : {}, __copyProps(isNodeMode || !mod || !mod.__esModule ? __defProp(target, "default", {
+	value: mod,
+	enumerable: true
+}) : target, mod));
+
+//#endregion
+export { __commonJS, __export, __toESM };