wasm-compatibility

An automated checker that determines whether a marimo notebook can run in a WebAssembly environment (the marimo playground, community cloud, or an exported WASM HTML file) and reports any blockers. Because WASM notebooks execute through Pyodide in the browser, the review focuses on package availability and browser-sandbox limitations rather than ordinary Python correctness.

The process starts by reading the notebook and extracting every dependency from two sources: the PEP 723 script metadata block and the import statements in the cells, using a mapping table to translate import names such as sklearn or cv2 into their PyPI distribution names. Each package is then classified: standard-library modules mostly work, but several do not, including multiprocessing, subprocess, sqlite3, pdb, tkinter, and readline, with threading treated only as a warning. Pyodide built-in packages work out of the box, pure-Python packages can install at runtime via micropip, and packages with native C or Rust extensions not built for Pyodide, such as torch, tensorflow, jax, psycopg2, grpcio, and psutil, will fail.

The checker also scans code for patterns that break in the browser, including process spawning, hard-coded absolute file paths, sqlite3 connections, breakpoints, environment-variable reads, and large dataset loads against the 2 GB memory cap, offering a suggested fix for each. It verifies that dependencies are listed in the PEP 723 block so they auto-install, noting that version pins are stripped in WASM. The final report gives an overall verdict of PASS, WARN, or FAIL, a per-package status table, a list of code issues with their locations, and concrete recommendations such as substituting WASM-friendly alternatives or moving heavy computation to a hosted API.