v3/examples/ios/go.mod (1)

3-3: Same Go 1.25 version concern as other modules.

See comment on gin-example/go.mod regarding Go version verification.

v3/UNRELEASED_CHANGELOG.md (1)

20-20: Optional: include PR reference in changelog entry.
Helps traceability in the release notes.

📝 Suggested tweak

-- Add experimental server mode for headless/web deployments (`-tags server`). Enables running Wails apps as HTTP servers without native GUI dependencies. Build with `wails3 task build:server`. See `examples/server` for details.
+- Add experimental server mode for headless/web deployments (`-tags server`). Enables running Wails apps as HTTP servers without native GUI dependencies. Build with `wails3 task build:server`. See `examples/server` for details. (`#4903`)

v3/internal/commands/build_assets/docker/Dockerfile.server (2)

18-22: Add go mod download before build for better Docker layer caching.

Running go mod tidy ensures module consistency, but adding an explicit go mod download step allows Docker to cache dependencies separately from source changes, improving rebuild times.

Suggested improvement

 # Remove local replace directive if present (for production builds)
 RUN sed -i '/^replace/d' go.mod || true

-# Download dependencies
+# Download dependencies (separate layer for caching)
 RUN go mod tidy
+RUN go mod download

 # Build the server binary
 RUN go build -tags server -ldflags="-s -w" -o server .

---

30-31: Hardcoded frontend path assumes specific project structure.

The path /app/frontend/dist assumes a standard Vite/frontend build output location. If a project uses a different frontend structure or output directory, this COPY will fail. Consider documenting this assumption or making it configurable via build args.

Optional: Add ARG for flexibility

+ARG FRONTEND_DIST=frontend/dist
+
 # Copy frontend assets
-COPY --from=builder /app/frontend/dist /frontend/dist
+COPY --from=builder /app/${FRONTEND_DIST} /frontend/dist

v3/internal/runtime/desktop/@wailsio/runtime/src/index.ts (1)

88-98: Promise resolves before script execution completes.

The function returns a Promise that resolves after the HEAD check and script tag injection, but before the script has actually loaded and executed. If callers need to wait for the script to be ready, they'll get a false positive.

For the current use case (line 101), this is acceptable since custom.js is fire-and-forget. However, since this is a public export, consider documenting this behavior or optionally waiting for script load.

Optional: Wait for script load

 export function loadOptionalScript(url: string): Promise<void> {
     return fetch(url, { method: 'HEAD' })
         .then(response => {
             if (response.ok) {
-                const script = document.createElement('script');
-                script.src = url;
-                document.head.appendChild(script);
+                return new Promise<void>((resolve) => {
+                    const script = document.createElement('script');
+                    script.src = url;
+                    script.onload = () => resolve();
+                    script.onerror = () => resolve(); // Still resolve - script is optional
+                    document.head.appendChild(script);
+                });
             }
         })
         .catch(() => {}); // Silently ignore - script is optional
 }

v3/pkg/application/application_options.go (1)

137-165: Consider adding TLS configuration options for production hardening.

The ServerOptions struct provides good defaults and documentation. For production server deployments, consider extending TLSOptions to support:

• MinVersion (e.g., TLS 1.2 minimum)
• Custom *tls.Config for advanced scenarios

This is optional since users can wrap/proxy the server, but could be valuable for standalone deployments.

💡 Optional enhancement for TLSOptions

// TLSOptions configures HTTPS for the headless server.
type TLSOptions struct {
	// CertFile is the path to the TLS certificate file.
	CertFile string

	// KeyFile is the path to the TLS private key file.
	KeyFile string

	// MinVersion is the minimum TLS version (e.g., tls.VersionTLS12).
	// Default: tls.VersionTLS12
	MinVersion uint16
}

v3/Taskfile.yaml (1)

395-401: Test filter may be overly restrictive.

The -run TestServerMode filter only runs tests matching that specific pattern. As the server mode codebase grows, you may want to run all server-tagged tests:

💡 Consider broader test coverage

   test:server:
     summary: Run server mode unit tests
     dir: 'pkg/application'
     cmds:
       - echo "Running server mode tests..."
-      - go test -tags server -v -run TestServerMode .
+      - go test -tags server -v .
       - echo "✅ Server mode tests passed"

Alternatively, if you want to keep tests isolated, consider using a naming convention like TestServer* for all server-related tests.

v3/examples/server/Taskfile.yml (1)

23-30: The sources directive serves no purpose here.

The sources directive is used to determine if a task should re-run based on file changes. However, with only a precondition and no commands, specifying sources has no effect. Consider removing it for clarity.

Suggested simplification

  build:frontend:
    summary: Ensures frontend assets exist (static HTML, no build needed)
    dir: frontend
-   sources:
-     - dist/index.html
    preconditions:
      - sh: test -f dist/index.html
        msg: "frontend/dist/index.html not found"

v3/pkg/application/browser_window.go (1)

66-68: Consider returning meaningful errors for unsupported operations.

Methods like GetScreen() return (nil, nil) and Print() returns nil. In server mode, these operations are genuinely unsupported. Returning a sentinel error (e.g., ErrNotSupported) would help callers distinguish "not supported" from "succeeded with no result."

Example pattern

var ErrNotSupportedInServerMode = errors.New("operation not supported in server mode")

func (b *BrowserWindow) GetScreen() (*Screen, error) { 
    return nil, ErrNotSupportedInServerMode 
}

func (b *BrowserWindow) Print() error { 
    return ErrNotSupportedInServerMode 
}

v3/examples/server/main.go (2)

57-60: Hardcoded URLs may be misleading when env vars override configuration.

The log messages display localhost:8080 but the actual host/port can be overridden via WAILS_SERVER_HOST and WAILS_SERVER_PORT environment variables. Consider reading the effective values or noting this caveat.

---

68-77: Goroutine lacks graceful shutdown.

The ticker goroutine runs indefinitely and doesn't stop when the application shuts down. While this is acceptable for an example, consider using a context or shutdown channel for clean termination.

♻️ Suggested improvement

+	ctx, cancel := context.WithCancel(context.Background())
+	app.OnShutdown(func() {
+		cancel()
+	})
+
 	// Emit periodic events to test WebSocket broadcasting
 	go func() {
 		time.Sleep(2 * time.Second) // Wait for server to start
 		ticker := time.NewTicker(5 * time.Second)
 		defer ticker.Stop()
-		for {
-			<-ticker.C
-			app.Event.Emit("server-tick", time.Now().Format(time.RFC3339))
-			log.Println("Emitted server-tick event")
+		for {
+			select {
+			case <-ctx.Done():
+				return
+			case <-ticker.C:
+				app.Event.Emit("server-tick", time.Now().Format(time.RFC3339))
+				log.Println("Emitted server-tick event")
+			}
 		}
 	}()

Note: You'll need to add "context" to the imports.

v3/pkg/application/application_server_test.go (1)

45-46: Consider using a retry loop instead of fixed sleep for server startup.

Using time.Sleep(200 * time.Millisecond) to wait for server startup can be flaky in CI environments under load. A retry loop with backoff would be more robust.

v3/pkg/application/websocket_server.go (3)

103-107: Minor race condition: len(b.clients) accessed after releasing lock.

The log statement accesses len(b.clients) after the mutex is released, which could show a stale count if another goroutine modifies the map concurrently. This is only a cosmetic issue for logging.

♻️ Suggested fix

 func (b *WebSocketBroadcaster) register(conn *websocket.Conn, window *BrowserWindow) {
 	client := &clientInfo{
 		conn:   conn,
 		window: window,
 	}
 	b.mu.Lock()
 	b.clients[conn] = client
+	clientCount := len(b.clients)
 	b.mu.Unlock()
-	b.app.info("WebSocket client connected", "id", window.Name(), "clients", len(b.clients))
+	b.app.info("WebSocket client connected", "id", window.Name(), "clients", clientCount)
 }

---

109-122: Same race condition in unregister for logging.

Similar to register, len(b.clients) is accessed after the mutex is released.

♻️ Suggested fix

 func (b *WebSocketBroadcaster) unregister(conn *websocket.Conn, runtimeClientID string) {
 	b.mu.Lock()
 	client := b.clients[conn]
 	delete(b.clients, conn)
 	if runtimeClientID != "" {
 		delete(b.windows, runtimeClientID)
 	}
+	clientCount := len(b.clients)
 	b.mu.Unlock()
 	conn.Close(websocket.StatusNormalClosure, "")
 	if client != nil {
-		b.app.info("WebSocket client disconnected", "id", client.window.Name(), "clients", len(b.clients))
+		b.app.info("WebSocket client disconnected", "id", client.window.Name(), "clients", clientCount)
 	}
 }

---

62-65: Security note: InsecureSkipVerify: true allows any origin.

This is appropriate for server mode where browser clients connect from various origins, but consider adding a configuration option in ServerOptions to restrict allowed origins for production deployments that need stricter CORS control.