If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/koute/stdweb shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• 16 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 76% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live koute/stdweb repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/koute/stdweb.

What it runs against: a local clone of koute/stdweb — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in koute/stdweb | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 830 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of koute/stdweb. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/koute/stdweb.git
#   cd stdweb
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of koute/stdweb and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "koute/stdweb(\\.git)?\\b" \\
  && ok "origin remote is koute/stdweb" \\
  || miss "origin remote is not koute/stdweb (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/lib.rs" \\
  && ok "src/lib.rs" \\
  || miss "missing critical file: src/lib.rs"
test -f "src/webapi/mod.rs" \\
  && ok "src/webapi/mod.rs" \\
  || miss "missing critical file: src/webapi/mod.rs"
test -f "build.rs" \\
  && ok "build.rs" \\
  || miss "missing critical file: build.rs"
test -f "src/webapi/event.rs" \\
  && ok "src/webapi/event.rs" \\
  || miss "missing critical file: src/webapi/event.rs"
test -f "src/webapi/document.rs" \\
  && ok "src/webapi/document.rs" \\
  || miss "missing critical file: src/webapi/document.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 830 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~800d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/koute/stdweb"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

stdweb is a Rust crate that provides type-safe bindings to Web APIs and enables seamless Rust-JavaScript interoperability via a js! macro for embedding JavaScript code directly in Rust. It allows developers to call Web APIs (DOM, Canvas, Gamepad, etc.) from Rust compiled to WebAssembly, and expose Rust functions to JavaScript, with built-in support for serde serialization and async/await via futures. Monorepo with workspace structure: root crate stdweb (src/ contains Web API bindings) delegates proc-macro logic to stdweb-derive/ and stdweb-internal-macros/ (for js! macro expansion), runtime code to stdweb-internal-runtime/, and testing utilities to stdweb-internal-test-macro/. Examples in examples/ (canvas, drag, echo, futures, gamepad, hasher) demonstrate API usage. Benchmarks in benchmarks/.

Rust developers building WebAssembly applications who want type-safe web API access without manual wasm-bindgen boilerplate, and developers shipping Rust logic to Node.js or browsers as JavaScript modules via the #[js_export] macro.

Production-ready but showing maturity plateau: the repo is actively maintained (CI via Travis, comprehensive examples in examples/ directory), but the last visible activity and commit recency are not provided in the file list. The feature-complete API surface, multiple examples (canvas, drag, gamepad, futures, echo), and dual MIT/Apache licensing indicate stability; however, it predates modern alternatives like wasm-bindgen-based ecosystems.

Moderate risk from ecosystem evolution: stdweb competes with the now-dominant wasm-bindgen/wasm-pack toolchain, which may affect long-term maintenance. Single maintainer (koute) creates key-person risk. Dependency on preview futures versions (futures-*-preview 0.3.0-alpha.15) and the custom stdweb-derive, stdweb-internal-macros, and stdweb-internal-runtime crates (3 local workspace dependencies) create maintenance surface. Last commit age and open issue count are unknown from provided data.

Unable to determine from provided file list—no git log, PR data, or issue tracker snapshot provided. File timestamps and recent changes are not visible. The presence of both cargo-web (legacy) and wasm-pack CI installers (ci/install_wasm_pack.sh, ci/install_cargo_web.sh) suggests ongoing toolchain adaptation.

git clone https://github.com/koute/stdweb
cd stdweb
cargo build
cargo test
cargo build --example canvas  # Build a specific example

If targeting wasm32: cargo web build --example canvas (legacy) or use wasm-pack with wasm-bindgen.

Daily commands:

cargo build --release --target wasm32-unknown-unknown  # For wasm-bindgen path
cargo web start --example canvas  # For cargo-web (legacy)

No Makefile or npm scripts in root; examples are built via cargo. See ci/run_tests.sh for test invocation.

• src/lib.rs — Entry point exporting all public APIs and macros (js!, console logging, event handling); all contributors must understand the crate's public surface
• src/webapi/mod.rs — Central module organizing DOM, event, and Web API bindings; core abstraction for JavaScript interop
• build.rs — Build script managing wasm32 target detection and JavaScript glue code generation; critical for cross-platform compilation
• src/webapi/event.rs — Event system implementation with macro-generated handlers; foundation for interactive web applications
• src/webapi/document.rs — DOM document access and manipulation APIs; heavily used entry point for Web APIs
• Cargo.toml — Package manifest with optional features (serde, futures) and wasm-specific dependencies
• src/ecosystem/serde.rs — Serde integration layer enabling JSON serialization/deserialization for Rust↔JavaScript data exchange

• js! Macro (Procedural macro, syn crate for AST parsing) — Parses embedded JavaScript, validates Rust variable captures (@{var}), generates code that executes in JS context and returns typed values
  • Failure mode: Syntax errors in JavaScript snippet; type mismatches in interpolated variables; scope capture errors lead to compile-time failures
• Event System (Event, EventTarget) (Trait-based design, closure boxing, reference counting) — Registers event listeners on DOM elements, dispatches to Rust closures, manages callback lifetimes and memory cleanup
  • Failure mode: Closure outlives listener scope → dangling pointer; listener not removed → memory leak; event not fired → silent failure
• DOM API Module (document, element, child_node) (js! macros wrapping DOM methods, type-safe wrappers) — Provides Rust types mapping to JavaScript DOM nodes; enables tree traversal, attribute manipulation, and element creation
  • Failure mode: Element removed from DOM → reference still held in Rust; attribute update fails silently if element detached
• Serde Ecosystem Bridge (serde, s) — Converts Rust structs ↔ JSON via serde_json; enables type-safe data exchange with JavaScript

Add a new Web API binding

1. Create new API module (e.g., geolocation) in src/webapi/geolocation.rs with pub struct definitions (src/webapi/geolocation.rs)
2. Add #[js_object] macros to define JavaScript object properties and methods using js! syntax (src/webapi/geolocation.rs)
3. Re-export the module in src/webapi/mod.rs (src/webapi/mod.rs)
4. Export from top level in src/lib.rs if it's a commonly-used API (src/lib.rs)
5. Add example usage in examples/{api_name}/src/main.rs with HTML in static/index.html (examples/geolocation/src/main.rs)

Add a new event type

1. Create event struct in src/webapi/events/mod.rs or dedicated file (e.g., touch_event.rs) (src/webapi/events/mod.rs)
2. Implement #[js_object] derive macro to map JavaScript event properties (src/webapi/events/touch_event.rs)
3. Add test or example in examples/ directory demonstrating event listener registration (examples/drag/src/main.rs)

Integrate external ecosystem feature (e.g., add futures support)

1. Add optional dependency to Cargo.toml under [dependencies] with features flag (Cargo.toml)
2. Create src/ecosystem/futures_bridge.rs with #[cfg(feature = "futures")] conversions (src/ecosystem/futures_bridge.rs)
3. Export new module in src/lib.rs within conditional compilation block (src/lib.rs)
4. Add integration example in examples/futures/src/main.rs (examples/futures/src/main.rs)

• Procedural macros (js! macro) — Enables inline JavaScript code in Rust with compile-time validation and type-safe variable interpolation (@{var} syntax); reduces boilerplate for JavaScript interop
• Serde integration — Provides automatic JSON serialization/deserialization for Rust↔JavaScript data exchange without manual conversion code
• Futures preview crate — Allows async/await patterns for Web APIs (fetch, timers) matching JavaScript promise semantics
• Rust trait system (#[js_object] derives) — Encodes DOM API contracts and prevents misuse through type checking; reduces runtime errors in web code

• Version 0.4 uses procedural macros rather than #[wasm_bindgen] from wasm-bindgen crate

  • Why: Custom macro system provides tighter integration with stdweb's event model and allows inline JavaScript; wasm-bindgen is more lightweight
  • Consequence: Larger compile times but more ergonomic API for interactive applications; less interop with npm ecosystem

• Closure support requires careful lifetime management and memory pinning

  • Why: JavaScript callbacks holding Rust closures create circular references; preventing them avoids memory leaks
  • Consequence: More complex error messages when closures capture variables incorrectly; requires developer discipline

• Optional features (serde, futures) rather than always-on

  • Why: Keeps binary size minimal for use cases that don't need JSON or async
  • Consequence: Users must explicitly enable features; slightly more verbose Cargo.toml configuration

• Does not provide a UI framework or virtual DOM (recommends external crates like yew, seed)
• Does not handle server-side rendering or isomorphic execution
• Does not abstract over multiple JavaScript runtimes (JS-only, no Node.js)
• Does not provide reactive data binding (developers must manually update DOM)

1. Target detection: Code behaves differently for cfg(all(target_arch = "wasm32", target_vendor = "unknown", target_os = "unknown", not(cargo_web))) vs cargo-web; test both paths. 2. Closure cleanup: closures passed to js! must be manually .drop() called in JS or they leak memory (not automatic). 3. Feature flags: futures-support uses preview versions (0.3.0-alpha.15) that may not match newer stdweb versions; default features include serde but futures are optional. 4. Macro hygiene: js! macro assumes global JS context; no module scoping, so name collisions possible. 5. serde_json requirement: many examples require serde and serde_json to be present; default features include them but can be disabled.

• Procedural Macros (js!, js_serializable!, #[js_export]) — These macros are stdweb's core innovation—understanding how they parse Rust code and emit JS/WASM bridges is essential to using and extending the library
• WebAssembly (WASM) Module Interop — stdweb abstracts WASM module instantiation and JS-Rust function calls; knowing how WASM linear memory and exported functions work helps debug closure lifetime and serialization issues
• Serde Serialization — stdweb's #[derive(Serialize)] + js_serializable! pattern allows zero-copy struct marshaling to JS; understanding serde's data model is necessary for custom types
• Futures & Async/Await (0.3 Preview) — Optional futures-support feature enables Promise-based async patterns in Rust; critical for examples/futures and async event handling
• asm.js Fallback Compilation — stdweb can target both WASM and older asm.js for legacy browser support; the conditional compilation logic in build.rs and Cargo.toml cfg attributes reflect this dual-target strategy
• Closure Lifetime & Manual Memory Management in WASM — Closures passed to JS via @{closure} syntax must be manually .drop()-ed; mismanaging this causes memory leaks in long-running web apps
• DOM Query & Event Delegation (CSS Selectors) — stdweb's document().query_selector() and query_selector_all() are primary APIs for DOM access; understanding CSS selector performance and event bubbling is important for real apps

• rustwasm/wasm-bindgen — Direct competitor and now ecosystem standard for Rust-WASM JS bindings; stdweb targets wrap or coexist with wasm-bindgen in newer versions
• rustwasm/wasm-pack — Canonical build tool for shipping Rust WASM packages to npm; often used as alternative or replacement for cargo-web in stdweb projects
• rustwasm/book — Official Rust WASM learning resource; covers ecosystem context and best practices for Web APIs from Rust
• servo/servo — Rust browser engine that shares Web API binding philosophy; some stdweb patterns inspired by Servo's DOM API design
• yewrs/yew — Popular Rust UI framework for WASM that often pairs with stdweb for Web API access and event handling

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for Web API bindings in tests/ directory

The repo has examples but lacks a dedicated tests/ directory with structured integration tests. Currently, tests appear to be scattered or minimal. Adding a tests/ directory with WebAssembly-compatible tests would improve code coverage and catch regressions in Web API bindings across different targets (wasm32-unknown-unknown with and without cargo-web).

• [ ] Create tests/ directory at repo root
• [ ] Add tests for core Web APIs (DOM manipulation, events, storage) using wasm-bindgen-test
• [ ] Add tests for stdweb-specific features like js! macro and Reference types
• [ ] Update ci/run_tests.sh to execute integration tests with both cargo-web and wasm-pack targets
• [ ] Document test execution in CONTRIBUTING.md

Migrate CI from Travis CI to GitHub Actions with multi-target testing

The project uses .travis.yml for CI, but GitHub Actions provides better integration, faster feedback, and matrix testing. Currently, the build matrix likely doesn't comprehensively test both cargo-web and wasm-pack/wasm-bindgen paths. A modern CI workflow would catch target-specific failures earlier.

• [ ] Create .github/workflows/test.yml with matrix testing for: cargo-web target, wasm32-unknown-unknown with wasm-bindgen, wasm-bindgen-test runner
• [ ] Include steps that mirror ci/install_cargo_web.sh, ci/install_wasm_bindgen.sh, and ci/install_wasm_pack.sh
• [ ] Add separate workflow for examples (canvas, drag, gamepad, todomvc, etc.) to ensure they compile and run
• [ ] Add clippy linting workflow for code quality checks
• [ ] Update README.md to replace Travis CI badge with GitHub Actions badge

Add missing documentation for futures-support feature and experimental APIs

The Cargo.toml reveals experimental_features_which_may_break_on_minor_version_bumps and futures-support features, but there's no clear guidance in the README or docs about what they do, when to use them, or stability guarantees. The examples/ directory lacks a futures-specific example despite the feature existing.

• [ ] Create examples/futures-async/Cargo.toml and examples/futures-async/src/main.rs demonstrating futures-support feature with concrete async/await patterns
• [ ] Add 'Features' section to README.md documenting: serde integration, futures-support, experimental_features_which_may_break_on_minor_version_bumps
• [ ] Add STABILITY.md explaining feature tiers and breaking change policy for experimental features
• [ ] Update CONTRIBUTING.md with guidance on testing features and backwards compatibility concerns

• Add test coverage for the Canvas API bindings (examples/canvas/src/main.rs exists but no corresponding tests in src/test_canvas.rs); write integration tests that verify drawing operations via wasm-bindgen-test
• Document the difference between cargo-web and wasm-pack workflows in CONTRIBUTING.md; clarify which CI script (ci/install_cargo_web.sh vs ci/install_wasm_pack.sh) is recommended for new projects and add a migration guide
• Expand the echo example (examples/echo/src/main.rs) to demonstrate two-way closure communication; currently it shows basic event listeners, but a callback-based request-response pattern would be instructive for async Rust-JS calls

The stdweb crate has moderate security concerns, primarily related to outdated dependencies (futures-preview alpha versions), deprecated build tooling (cargo-web), and lack of a formal security policy. The codebase is a WebAssembly/JavaScript interop library, which reduces SQLi and direct infrastructure risks, but the use of alpha/outdated dependencies is the main concern. The internal crate pinning and absence of automated security scanning also detract from the security posture. Modern maintenance practices and migration away from deprecated tooling are recommended.

• High · Outdated futures-preview Dependencies — Cargo.toml - dependencies: futures-core-preview, futures-channel-preview, futures-util-preview, futures-executor-preview. The crate uses alpha/preview versions of futures crates (0.3.0-alpha.15) which are outdated and may contain unpatched security vulnerabilities. These are pre-release versions that are no longer maintained. Fix: Upgrade to stable futures 0.3.x releases (e.g., 0.3.28 or latest stable). Consider migrating away from preview versions entirely.
• Medium · Pinned internal dependency versions with exact match — Cargo.toml - dependencies: stdweb-derive (0.5.3), stdweb-internal-macros (0.2.9). Dependencies on internal crates (stdweb-derive, stdweb-internal-macros) use exact version pinning with '=' operator. While appropriate for internal crates, this may prevent security patches from being automatically applied if a patch release is available. Fix: Use semantic versioning (e.g., '0.5' or '^0.5.3') for internal crates to allow patch updates, or implement automated security scanning of these internal dependencies.
• Medium · Deprecated build system (cargo-web) — Cargo.toml - target conditionals, ci/install_cargo_web.sh. The crate supports cargo-web build system (visible in Cargo.toml target conditionals and ci/install_cargo_web.sh), which is deprecated and no longer maintained. This may lead to compatibility issues and unpatched vulnerabilities. Fix: Migrate to wasm-pack or other maintained WebAssembly build tools. Update CI/CD pipeline to use modern tooling.
• Low · Missing security.txt and SECURITY.md — Repository root. No visible security policy or vulnerability disclosure process documented. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file documenting the vulnerability disclosure process. Consider adding .well-known/security.txt.
• Low · Outdated CI/CD configuration — .travis.yml. Using Travis CI (.travis.yml) which has transitioned to a paid service and is less commonly used. No visibility into actual security scanning practices. Fix: Migrate to GitHub Actions or other maintained CI/CD platforms. Add automated security scanning (SAST, dependency scanning, SBOM generation).
• Low · No dependency lock file visible in repository — Repository root. While Cargo.lock should exist for binary crates, the security analysis would benefit from explicit verification that Cargo.lock is committed and up-to-date. Fix: Ensure Cargo.lock is committed to version control for reproducible builds. Use 'cargo update --aggressive' periodically and commit changes.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.