tsify is a Rust library that generates TypeScript type declarations from Rust types, primarily for the wasm-bindgen ecosystem. The core mechanism is a `#[derive(Tsify)]` proc macro that produces a `Tsify` trait impl whose `DECL` constant is emitted into the wasm-bindgen `typescript_custom_section`, so `wasm-pack` automatically appends the generated `.d.ts` alongside the JS output. It maps Rust structs, enums, and type aliases to TypeScript interfaces, type aliases, namespaces, and unions, respecting serde attributes (`rename`, `tag`, `untagged`, `flatten`, `skip`, `default`, `transparent`) and offering tsify-specific overrides (`type`, `type_params`, `type_prefix`/`type_suffix`, `rename`, `namespace`, and serializer options like `missing_as_null` / `hashmap_as_object` / `large_number_types_as_bigints`). A second runtime type, `Ts<T>`, provides a memory-safe alternative to the deprecated `into_wasm_abi`/`from_wasm_abi` attributes by deferring deserialization out of the infallible ABI boundary into the function body, avoiding the destructor-skipping `throw_str` leak path.
libopus-wasm is a TypeScript library that provides WebAssembly bindings for libopus, enabling raw Opus packet encode/decode in browsers and Node.js without native dependencies. It exposes async factories (`createEncoder`, `createDecoder`) that lazily load a single-file WASM module, returning typed handles with methods for Int16 and Float32 PCM, batch operations, packet-loss concealment, in-band FEC, and a curated CTL passthrough. The library also ships a `@discordjs/opus`-compatible adapter (`libopus-wasm/discordjs`) for drop-in replacement. The codebase is well-structured with strict validation, deterministic cleanup via `Symbol.dispose`, and comprehensive test coverage. Build scripts compile libopus from source using Emscripten with SHA-256 verification, and the documentation site is generated from Markdown by a custom static site builder. The repository is actively maintained with recent commits, CI across Node 22–26, and no open issues.
plotters is a Rust data visualization library that provides a high-level API for creating charts and plots. It supports multiple backends (bitmap, SVG, canvas, WASM) via the `DrawingBackend` trait, allowing output to PNG, SVG, GIF, or interactive Jupyter notebooks. The core crate `plotters` offers chart builders, coordinate systems, drawable elements, series, and styles, while backend crates (`plotters-bitmap`, `plotters-svg`) implement the trait. Key entry points include `ChartBuilder`, `DrawingArea`, and backend constructors like `BitMapBackend::new`. Data flows involve user-provided iterators transformed into drawable elements via series (e.g., `LineSeries`, `Histogram`) and rendered to the chosen backend. External dependencies include `image`, `chrono`, `font-kit`, `ab_glyph`, `gif`, and `serde` (optional). The library is designed for embedding in Rust applications, not as a standalone tool, and is actively maintained with extensive examples, benchmarks, and CI.
This is a software library for parsing and processing IFC (Industry Foundation Classes) BIM files, primarily designed for web environments. It consists of a C++ core that reads IFC STEP files, resolves geometry (including extrusions, sweeps, Boolean CSG operations, and advanced curves like B-splines and clothoids), and generates triangulated meshes. The C++ code is compiled to WebAssembly via Emscripten, and a TypeScript API (IfcAPI) exposes all functionality to JavaScript applications in both browser and Node.js. The library supports multiple IFC schema versions (IFC2X3, IFC4, IFC4X3) and includes a schema generator that produces C++ and TypeScript type definitions from EXPRESS schema files. The architecture is a classic native-to-web bridge: the C++ library handles all heavy geometry and parsing, while the TypeScript layer provides a clean interface for loading models, streaming meshes, reading/writing properties, and creating new geometry. Key entry points include the IfcAPI class (open/close models, load geometry, save models), the C++ IfcGeometryProcessor and IfcGeometryLoader for mesh generation, and the IfcLoader for token-based IFC parsing. External dependencies include GLM (math), spdlog (logging), mapbox/earcut (triangulation), and CDT (constrained Delaunay triangulation). A comprehensive test suite using real IFC files and regression hash checks ensures geometry stability across versions. The library is production-ready but shows some technical drift: pinned dependency commits, large monolithic source files, and generated schema headers that must be manually regenerated. It remains actively maintained with CI/CD pipelines, issue triage, and regular releases (v0.0.78).
Nostalgist.js is a TypeScript library that provides a simplified API for running retro console emulators in web browsers using RetroArch compiled via Emscripten. It handles the complex setup of Emscripten modules, virtual file systems, and RetroArch configuration, allowing developers to launch games with minimal code. The library supports a wide range of consoles (NES, SNES, Game Boy, etc.) with sensible defaults for loading cores and ROMs from CDNs, while also allowing custom resolvers. It includes features like save/load states, SRAM management, screenshot capture, and programmatic input control. The codebase is well-structured with strong TypeScript types, comprehensive tests (integration and e2e), and a clean class hierarchy. Notable highlights include a flexible file resolution system that handles various input formats (URLs, Blobs, ArrayBuffers, etc.) and a clever patching mechanism for importing Emscripten modules as ES modules.
GKD is an open-source Android application that automates UI interactions, primarily to skip ads, auto-confirm dialogs, and perform custom click actions. It operates as an accessibility service, using a custom selector language (similar to CSS) to match UI nodes and execute actions defined in remote subscription rules. The app is built with Kotlin and Jetpack Compose, leveraging Room for local persistence, Ktor for HTTP, and Coroutines/Flow for reactive state management. It also integrates with Shizuku for privileged operations like input injection and screenshot capture. The architecture is modular: the main `gkd-app` module contains the UI, services, and rule engine; `gkd-selector` is a Kotlin Multiplatform library for parsing and matching the custom selector syntax; `gkd-db` provides a multiplatform database layer; and `gkd-hidden-api` contains stubs for Android hidden APIs used for automation. Key entry points include the accessibility service (`A11yService`), the subscription repository (`SubscriptionRepository`), and the snapshot capture system. Data flows involve downloading subscription rules, parsing them into internal representations, matching against accessibility node trees, and executing actions (click, swipe, etc.). External dependencies include AndroidX libraries, Ktor, Kotlin Serialization, Coil, and the Shizuku privilege library. The codebase demonstrates strong engineering practices with extensive unit tests, a well-defined selector engine, and reusable patterns like `Loadable` for async state and `MutexState` for concurrency. However, it relies heavily on hidden Android APIs and a custom DSL, which introduces maintenance risk. Overall, it is a high-quality, actively maintained project with significant reuse potential in its selector engine and utility components.
Jco is a JavaScript toolchain for WebAssembly components. It transpiles WASM components to JavaScript, generates TypeScript types from WIT, bundles components, and provides a standard library (`jco-std`) that ports Node.js built-in modules (fs, http, tls, net, crypto, zlib, etc.) to run inside WebAssembly components via WASI Preview 2/3. The monorepo contains a Rust workspace (bindgen crates, test components) and TypeScript packages (jco CLI, jco-transpile, preview2-shim, preview3-shim, jco-std). The codebase is notable for its differential testing approach: shims are tested against native Node.js behavior, with tests for HTTP/2, TLS, SQLite, streams, and worker threads. A dual-adapter pattern (deny-by-default vs. Node-native) ensures security by default. The project supports multiple WASI versions (0.2.x, 0.3.x) and Node.js versions (24.x, 26.x), with dedicated shims for browser and Node.js runtimes. Maintenance is active (recent commits, CI workflows), but there are drift risks: pinned Node.js versions, many TODO comments, incomplete browser shims (throwing Todo), and experimental features like JSPI and async support.
wac is a CLI tool and library for composing WebAssembly components using the WAC language, a declarative superset of WIT. It parses .wac files, resolves package references from the filesystem or a Warg registry, builds a directed acyclic composition graph, and encodes the result into a valid WebAssembly component binary (.wasm). The system is modular, with four core crates: wac-parser (lexer, AST, name resolution), wac-resolver (package resolution with filesystem and registry backends), wac-graph (graph representation and binary encoding), and wac-types (type system, subtype checking, semver-aware type aggregation). The CLI exposes commands such as `plug`, `compose`, `targets`, `parse`, and `resolve`, each targeting a specific composition workflow. The architecture follows a pipeline: WAC source text → lexing/parsing → AST resolution (name binding, type checking) → composition graph construction → binary encoding. The resolver supports both local `.wat`/`.wasm` files and remote packages from a Warg registry (feature-gated). The type system includes full component model types (primitives, records, variants, resources, streams, futures, functions, interfaces, worlds) with async function support and semver-aware compatibility checks. The composition graph handles imports, instantiations, aliases, exports, and argument wiring, and can merge compatible imports from multiple packages. External dependencies include the Bytecode Alliance ecosystem: wit-parser, wasmparser, wit-component, wasm-encoder, wasmprinter, wat, and optionally warg-client and warg-protocol for registry support. The project is actively developed with extensive test coverage, including roundtrip parsing, resolution error cases, graph encoding, and registry integration tests. It is published on crates.io and provides prebuilt binaries for Linux, macOS, and Windows.
Liam is a full-stack web application and CLI toolchain for database schema design and visualization. It parses schemas from multiple formats (PostgreSQL, Prisma, Drizzle, tbls, schema.rb), renders interactive Entity-Relationship Diagrams (ERDs) using React Flow, and provides an AI-assisted workflow powered by LangGraph agents. Users can create design sessions, chat with a team of AI agents (PM, DB, QA) that analyze requirements, generate schema changes, create migration SQL, and validate via pgTAP tests. The frontend is built with Next.js and Supabase for authentication, real-time updates, and data persistence. A CLI tool allows local ERD generation from schema files. The monorepo includes numerous internal packages for schema parsing, UI components, error handling (neverthrow), and in-browser PostgreSQL execution (PGlite).
JavaScriptKit is a production-grade Swift framework and Swift Package Manager plugin suite that enables bidirectional JavaScript interop for Swift code compiled to WebAssembly (WASM). The core runtime (JavaScriptKit) provides low-level types such as JSObject, JSValue, JSClosure, JSPromise, and JSBigInt, along with value conversion protocols (ConvertibleToJSValue, ConstructibleFromJSValue) and thread-local storage helpers. The BridgeJS plugin uses Swift macros (@JS, @JSFunction, @JSClass, etc.) to automatically generate Swift and JavaScript glue code, including WebAssembly export/import tables, stack-based marshalling, codec caches, and closure lifecycle management. The PackageToJS plugin packages the compiled WASM module into a deployable JavaScript package with platform-specific instantiation logic for browsers, Node.js, and WASI. The repository includes extensive snapshot-based code generation tests, runtime integration tests, benchmarks, and real-world examples (browser apps, Node.js servers, multithreading with web workers, OffscreenCanvas, actor-based concurrency). The architecture is a layered combination of a Swift library, Swift macros, a CLI tool (bridge-js), and SPM build plugins, all heavily dependent on WebAssembly-specific Swift features (@_expose(wasm), @_cdecl) and the Swift concurrency runtime. The project is actively maintained with a large test surface, but carries medium technical drift due to reliance on experimental Swift features and snapshot brittleness.
Fonnx is a Flutter plugin that enables cross-platform, on-device machine learning inference by wrapping the ONNX Runtime engine. It provides a unified Dart API that abstracts away the complexities of native FFI (for iOS, Android, macOS, Windows, Linux) and WebAssembly (for web), allowing developers to run models like OpenAI Whisper, Silero VAD, Magika, and various text embedding models without cloud dependencies. The codebase exhibits high software craftsmanship. Its architecture uses conditional Dart imports to cleanly separate native and web backends, employs Dart isolates for offloading heavy inference tasks, and implements a custom RPC protocol for web workers. A standout feature is its robust native memory management, including a C finalizer tested with sanitizers to prevent leaks during Flutter hot-restarts. While primarily a software library, it bridges the gap between ML research and production by bundling specific, optimized ONNX models and providing a deterministic test corpus with golden outputs. It is an excellent resource for Flutter developers building privacy-focused, offline-first AI applications, though its reliance on pinned native assets and specific build tooling introduces a moderate technical drift risk.
This repository provides a lightweight, LGPL-friendly FFmpeg and FFprobe compiled to WebAssembly for Node.js (and browser via a dedicated worker). It wraps the wasm modules with predictable CLI and TypeScript APIs for media probing, audio extraction, video resizing, thumbnail generation, raw frame output, stream-copy clips, and segmentation. The architecture consists of a TypeScript library that spawns a child process running an Emscripten-generated module, with both buffered (runFfmpeg, runFfprobe) and streaming (execFfmpeg, execFfprobe) APIs. A browser-only ffmpac worker enables the same operations in the included media workbench playground. The build system is sophisticated: it fetches FFmpeg, LAME, and libvpx source, compiles them statically with Emscripten, and produces both Node and browser wasm bundles. The codebase is well-structured, with strict linting, comprehensive unit and E2E tests, and a clear separation of concerns. It is actively maintained and demonstrates strong engineering practices.
OGRE (Object-Oriented Graphics Rendering Engine) is a mature, production-grade 3D rendering engine written in C++ with extensive cross-platform support. The codebase implements a modular plugin architecture with render system backends for Direct3D 9/11, OpenGL (legacy, 3+, ES2), Metal, Vulkan, and a software Tiny renderer. Core modules include scene management, material/shaders, resource handling, animation, particle systems, and compositor framework. Optional components provide real-time shader generation (RTShaderSystem), automatic mesh LOD generation, terrain rendering, volume rendering, world paging, and a 2D overlay system. The repository also includes Python bindings, sample applications, fuzz testing, and content pipeline tools (exporters for Maya, Milkshape, Wings3D). The architecture follows design patterns such as Singleton managers, Factory-based extensibility, and a work queue for background loading. Despite its age and size, the engine remains actively maintained with recent commits, CI/CD pipelines, and support for modern graphics APIs. Notable technical debt includes legacy render backends, deprecated APIs, and some tightly coupled subsystems.
pacman.zig is a faithful recreation of the classic Pacman arcade game implemented in the Zig programming language. It uses the Sokol cross-platform libraries for graphics, audio, and input handling, allowing it to run as a native desktop application or be compiled to WebAssembly for browser play. The game implements all original Pacman mechanics including Pacman movement, ghost AI with distinct behaviors for each ghost, dot and pill eating, bonus fruits, sound effects, score tracking, and level progression. The architecture follows a monolithic design with clear separation of concerns into game state management, game logic, rendering, audio, and input systems. Despite being contained primarily in a single source file, the code is well-organized with distinct sections for different subsystems. The implementation demonstrates attention to detail in replicating the original game's behavior and performance characteristics.
Gloo is a modular Rust toolkit for WebAssembly that provides idiomatic, ergonomic wrappers around browser APIs. Instead of using raw `web-sys` or `js-sys` bindings, Gloo offers a collection of reusable crates covering timers, events, file I/O, storage, dialogs, console logging, networking (HTTP, WebSocket, EventSource), history management, rendering, and web workers. The architecture is a multi-crate workspace with an umbrella crate (`gloo`) that re-exports all sub-crates, allowing users to depend on the whole toolkit or individual crates. Key entry points are the public APIs of each crate, e.g., `EventListener`, `Timeout`, `Request`, `Blob`, `WorkerBridge`. Primary data flows are callbacks or futures/streams from JavaScript to Rust, with serialization handled by serde and postcard for workers. External dependencies include `wasm-bindgen`, `web-sys`, `js-sys`, `serde`, `futures`, and others. This is not a data research repository; it is a library/framework for building WebAssembly applications.
LiveSplit One is a cross-platform speedrun timer application, the successor to the classic LiveSplit timer. It runs as a Progressive Web App and as a Tauri desktop application, targeting Windows, Linux, and macOS. The core timing logic is compiled to WebAssembly via the 'livesplit-core' Rust library, while the UI is built with React 19, TypeScript, and Vite. The application provides a rich set of features for speedrunners: highly customizable split timers, real-time comparisons, layout editor with drag-and-drop, integrated leaderboards from Speedrun.com, global hotkeys (desktop only), always-on-top mode, WebSocket server for remote control, and support for multiple timekeeping methods (real time vs game time). Data persistence is handled via IndexedDB in the browser and the filesystem in Tauri. The codebase is well-structured with a clear separation between core logic (WASM), UI components, and platform-specific code, though some central components like 'LiveSplit.tsx' are large and could benefit from further decomposition.
Porcupine is a cross-platform wake word (keyword spotting) engine by Picovoice. The repository is a comprehensive SDK that provides native bindings for 10+ platforms including Android, iOS, Web (WASM), Python, Node.js, Java, .NET, Flutter, React Native, and embedded microcontrollers (STM32). The core engine is a proprietary binary (libpv_porcupine), but the repository contains all wrapper code, demos, and test infrastructure. The API is consistent across all bindings: a Porcupine class with init/process/release, a high-level PorcupineManager that handles microphone capture, and a set of built-in keywords for immediate use. The codebase demonstrates strong engineering practices: uniform error hierarchies, platform abstraction for library loading, and extensive CI/CD pipelines. The demos are production-quality and serve as integration templates. The repository is actively maintained with frequent commits and a large community (4.9k stars). The primary limitation is that the core engine is proprietary and requires a Picovoice access key, making the SDK itself not fully open-source. However, the binding code, patterns, and test infrastructure are reusable for other voice AI engines.
react-py is a React library that enables running Python code directly in the browser by leveraging Pyodide, a Python distribution compiled to WebAssembly. The library provides a PythonProvider context and two hooks (usePython and usePythonConsole) for executing Python scripts and interacting with an interactive console. Python execution occurs in a dedicated web worker via comlink-based RPC, preventing UI blocking. A service worker intercepts synchronous fetch requests from the worker to implement stdin input (e.g., input() function). The library supports loading Pyodide official packages and micropip-installable packages, file system operations (read/write/mkdir/rmdir), module watching for hot-reloading, execution timeouts, lazy worker initialization, and automatic package import detection. The architecture is cleanly separated into provider, hooks, worker scripts, and types, with the documentation site (Docusaurus) serving as both documentation and interactive playground.
RetroAssembly is a full-stack web application for self-hosting a personal retro game collection and playing it directly in the browser via emulation. It provides a complete library management system for ROMs, save states, favorites, and launch history, with a rich UI built on React 19, Radix UI, and Tailwind CSS 4. The backend uses Hono with Drizzle ORM and SQLite (Node.js) or Cloudflare D1 (Workers), with file storage abstracted for local filesystem or Cloudflare R2. Emulation is powered by Nostalgist.js using libretro cores, supporting dozens of platforms with per-platform core options, BIOS validation, shaders, rewind, and auto-save. The app features multi-user accounts with shared library mode, keyboard/gamepad navigation via spatial navigation, a virtual gamepad for touch devices, internationalization with 12 languages, and a Docker-first deployment model. The architecture is dual-runtime (Node.js or Cloudflare Workers), with a Vite-based build system and pnpm workspaces. While the codebase is well-structured and demonstrates strong engineering patterns, it carries medium technical drift due to pinned CDN commit hashes, patched third-party packages for SSR compatibility, and the complexity of maintaining dual runtimes.
WebPd is a compiler and runtime system that translates Pure Data (Pd) audio patches into JavaScript or WebAssembly, enabling real-time audio synthesis and processing in web browsers and Node.js environments. The codebase is structured as a TypeScript monorepo with a CLI tool (`webpd`), a browser runtime using AudioWorklet, and a comprehensive library of Pd object implementations (147+ objects). The core compilation pipeline parses `.pd` files, resolves abstractions, optimizes DSP graphs, and generates self-contained output formats including `.js`, `.wasm`, `.wav`, and standalone HTML apps. The architecture is modular: the `src/nodes/` directory contains individual builder and runtime implementations for each Pd object (osc~, dac~, filters, delay lines, message objects, etc.), all following a consistent `NodeBuilder` pattern with `translateArgs` and `build` methods. The compiler (`src/compile-dsp-graph/`) handles graph transformations like implicit signal mixing and message-to-signal conversion. The runtime layer (`src/environments/browser/`) provides initialization, AudioWorklet integration, and message passing between JavaScript and the compiled patch. The codebase demonstrates strong engineering practices with extensive parameterized tests that verify both JavaScript and WebAssembly outputs against golden fixtures. However, it is in alpha status (v1.0.0-alpha.14) with many incomplete features (e.g., `readsf~` state machine, `list` operations, `expr` if-form) and several TODO comments. The project relies on internal packages (`@webpd/compiler`, `@webpd/pd-parser`) that require coordinated builds, and some generated code strings are embedded in runtime files, creating potential maintenance friction. Despite these caveats, the compiler design, test infrastructure, and Pd compatibility are noteworthy.