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/Myriad-Dreamin/tinymist 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 the board

• Last commit 2w ago
• 14 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 69% 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 Myriad-Dreamin/tinymist repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Myriad-Dreamin/tinymist.

What it runs against: a local clone of Myriad-Dreamin/tinymist — 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 Myriad-Dreamin/tinymist | 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 main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 42 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Myriad-Dreamin/tinymist. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Myriad-Dreamin/tinymist.git
#   cd tinymist
#
# 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 Myriad-Dreamin/tinymist and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Myriad-Dreamin/tinymist(\\.git)?\\b" \\
  && ok "origin remote is Myriad-Dreamin/tinymist" \\
  || miss "origin remote is not Myriad-Dreamin/tinymist (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "crates/tinymist-query/src/lib.rs" \\
  && ok "crates/tinymist-query/src/lib.rs" \\
  || miss "missing critical file: crates/tinymist-query/src/lib.rs"
test -f "crates/tinymist/src/main.rs" \\
  && ok "crates/tinymist/src/main.rs" \\
  || miss "missing critical file: crates/tinymist/src/main.rs"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "contrib/html/editors/vscode/src/extension.mts" \\
  && ok "contrib/html/editors/vscode/src/extension.mts" \\
  || miss "missing critical file: contrib/html/editors/vscode/src/extension.mts"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 42 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~12d)"
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/Myriad-Dreamin/tinymist"
  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).

Tinymist is a language server (LSP) and integrated development environment for Typst, a modern markup language for scientific typesetting. It provides semantic highlighting, code completion, formatting, document symbols, code actions, and a live preview server—similar to how Rust-Analyzer serves Rust or Pylance serves Python, but specifically optimized for Typst's markup and scripting syntax. Monorepo structure with crates/ containing the core library (tinymist-query for analysis), CLI (tinymist binary wrapping the LSP), and ancillary crates; editors/vscode/ houses the TypeScript VSCode extension (685K lines); tests/ and benches/ are sibling directories. The Rust workspace uses shared dependencies via workspace.dependencies in Cargo.toml to avoid version drift. Configuration lives in .vscode/, .zed/, and workflow files in .github/workflows/.

Typst users writing scientific papers, theses, and technical documents who want IDE-like features (autocomplete, linting, instant preview) in their editor; also Typst extension maintainers for VSCode, Zed, and other editors integrating via LSP.

Actively developed and production-ready. The project has a mature CI/CD pipeline (.github/workflows/ with multiple build and release workflows), comprehensive Rust test coverage, and releases approximately monthly (version 0.14.16 as of workspace declaration). The codebase is 2.9M lines of Rust, indicating substantial implementation depth, though the project is relatively young compared to mature language servers.

Low risk for core LSP functionality but moderate API stability risk: the project is still pre-1.0 and makes breaking changes across minor versions (see CHANGELOG/CHANGELOG-2024.md and CHANGELOG/CHANGELOG-2025.md). Dependency surface is large (hyper, tokio, wasm-bindgen, fontdb, etc.) but well-maintained; single primary maintainer (Myriad-Dreamin) with contributions from others. The VSCode extension in editors/vscode/ has separate release cycles.

Active development with frequent releases: changelog entries dated 2025 indicate recent work on language features, bug fixes, and editor integrations. Multiple CI workflows (ci.yml, ci-check-e2e.yml) suggest ongoing testing. The AGENTS.md file hints at AI/automation integrations being explored. Nightly releases are automated via release-nightly.yml.

git clone https://github.com/Myriad-Dreamin/tinymist.git
cd tinymist
cargo build --release
cargo run --bin tinymist -- --help

For VSCode extension: cd editors/vscode && npm install && npm run compile.

Daily commands: LSP server: cargo run --bin tinymist -- --server starts the language server listening on stdio. Preview server: Built into the LSP; clients connect via the server's preview endpoints. VSCode extension: Open editors/vscode/ as a workspace (tinymist.code-workspace.tmpl.json), run F5 to launch debug instance, or npm run build to package.

• Cargo.toml — Workspace root configuration defining all member crates, dependencies, and Rust edition; essential for understanding build structure and dependency management
• crates/tinymist-query/src/lib.rs — Core analyzing library for Typst that provides query and analysis capabilities; foundational for all language service features
• crates/tinymist/src/main.rs — Entry point for the CLI and language server; defines the primary execution flow for tinymist's LSP functionality
• .github/workflows/ci.yml — CI pipeline configuration orchestrating tests, builds, and release workflows; critical for understanding project maturity and deployment
• contrib/html/editors/vscode/src/extension.mts — VSCode extension entry point providing IDE integration; shows how tinymist connects to the most common editor
• README.md — Project overview documenting purpose, features, and language service capabilities; essential starting point for new contributors
• CONTRIBUTING.md — Contribution guidelines and development setup instructions; mandatory reading for any code submission

• tinymist-query (Analysis Engine) (Rust, Typst parser APIs) — Parses Typst documents, builds symbol tables, extracts completions, checks diagnostics, and indexes references
  • Failure mode: Incorrect analysis leads to wrong completions, missed errors, or false diagnostics; corrupts symbol index
• Tinymist LSP Server (crates/tinymist) (Rust, LSP 3.x specification) — Implements LSP protocol, manages document state, dispatches analysis requests, and streams responses to editor clients
  • Failure mode: Crashes or deadlock stops IDE features; protocol violations cause editor client disconnection
• VSCode Language Client (contrib/html/editors/vscode) (TypeScript, VSCode Extension API, LSP client library) — Spawns LSP server process, forwards editor events, renders completions/diagnostics, provides keyboard shortcuts
  • Failure mode: Extension crashes disconnects IDE from server; UI hangs if client-server communication blocks
• CI/CD Pipeline (.github/workflows) (GitHub Actions, Cargo, ESBuild) — Tests code on multiple platforms, builds release artifacts, publishes to crates.io and GitHub Releases
  • Failure mode: Failed CI allows buggy code to merge; release workflow failure prevents version distribution

• VSCode Editor → Language Client Extension — User edits trigger textDocument/didChange notifications
• Language Client Extension → Tinymist LSP Server — Editor events (didChange, didOpen, completion requests) transmitted over LSP protocol (stdin/stdout)
• Tinymist LSP Server → tinymist-query — undefined

Add a new LSP language feature (e.g., code completion, hover)

1. Define the feature's analysis logic in the query library (crates/tinymist-query/src/lib.rs)
2. Expose the feature through the LSP protocol handler in the tinymist CLI (crates/tinymist/src/main.rs)
3. Wire the LSP response into VSCode's language client (contrib/html/editors/vscode/src/server.mts)
4. Add feature-specific tests in the integration test suite (tests)

Add a new editor integration (e.g., Neovim, Zed)

1. Create a new editor directory under contrib/html/editors/ (contrib/html/editors)
2. Implement language client that connects to tinymist LSP server (contrib/html/editors/[editor-name]/src/extension)
3. Configure editor-specific settings and keybindings (contrib/html/editors/[editor-name])
4. Add CI workflow to test the new integration (.github/workflows/ci.yml)

Release a new version of tinymist

1. Update version number in Cargo.toml workspace package (Cargo.toml)
2. Document changes in CHANGELOG (CHANGELOG/CHANGELOG-2025.md)
3. Create git tag matching version and push to trigger release workflow (.github/workflows/release.yml)
4. Verify artifacts published to crates.io and GitHub releases (.github/workflows/release-crates.yml)

• Rust + LSP — Provides type-safe, performant language server for Typst with direct LSP standard compliance; avoids runtime overhead of interpreted languages
• VSCode as primary IDE target — VSCode dominates the editor market and provides excellent extensibility via Language Server Protocol; easiest path to user adoption
• Workspace Cargo structure (multiple crates) — Enables modular architecture separating concerns: query engine, CLI, and language server can evolve independently without tight coupling
• GitHub Actions CI/CD — Native integration with GitHub repository; automated testing across platforms (Linux, macOS, Windows) and seamless release automation

• Single Rust binary for LSP server instead of multiple language-specific bindings

  • Why: Reduces maintenance burden and ensures consistent behavior across all editors
  • Consequence: Non-Rust editors require Language Client implementations that connect to the Rust binary; slower ecosystem adoption for non-VSCode editors

• Synchronous analysis in query library without streaming

  • Why: Simpler implementation and easier to reason about correctness for incremental parsing
  • Consequence: May block on large documents; future optimization may require refactoring to async analysis pipeline

• VSCode extension in TypeScript/JavaScript instead of Rust via WASM

  • Why: Faster development, familiar tooling for web developers, easier debugging in VSCode's extension environment
  • Consequence: VSCode plugin cannot be as feature-rich or performant; Rust logic lives only server-side

• Does not provide a full Typst compiler (uses Typst's own compiler APIs for rendering)
• Does not handle system-level package management or dependency resolution beyond Typst packages
• Not a text editor itself; is a service that integrates into existing editors
• Does not provide real-time collaborative editing features

Rust version: Requires Rust 1.91+ (specified in Cargo.toml); older toolchains will fail. Edition 2024: Uses latest edition syntax; MSRV pinning in workspace enforces this. Cross-platform font handling: fontdb crate requires native system font libraries on macOS/Linux; may fail silently if not available. wasm-bindgen: Web components in web-sys dependencies hint at potential WASM builds; ensure Node.js and wasm-pack are installed for full build. VSCode extension: Requires bundled Rust binary; extension build expects cargo build --release to succeed before npm run build. LSP protocol version: Hyper 1.0 and tower-lsp pin specific protocol versions; check compatibility if integrating with non-standard clients.

• Language Server Protocol (LSP) — Tinymist is fundamentally an LSP server; understanding the protocol lifecycle (initialize, didOpen, didChange, hover, completion) is essential to contributing any feature
• Abstract Syntax Tree (AST) traversal and semantic analysis — The tinymist-query crate walks Typst's AST to extract symbols, resolve references, and compute diagnostics; this is the backbone of all language features
• Incremental document synchronization — Tinymist handles didChange notifications with partial document updates (not full rewrites) for performance; understanding content ranges and text edit operations is crucial for the LSP handler layer
• WebSocket-based preview server — The live preview feature uses WebSocket (via hyper-tungstenite) to push compiled PDF updates to the editor in real-time; relevant for understanding the preview request flow in crates/tinymist/src/lsp/preview.rs
• Semantic tokens (semantic highlighting) — Tinymist provides semantic token types (keyword, function, variable, etc.) to VS Code for syntax-aware highlighting beyond simple regex patterns; stored in token classification logic throughout the analyzer
• WASM compilation targets — Workspace depends on wasm-bindgen and web-sys, suggesting Tinymist can compile to WebAssembly for browser-based environments; relevant for understanding cross-platform build matrix in .github/workflows/
• Workspace-level dependency management — The monorepo uses Cargo workspace with shared workspace.dependencies to avoid version conflicts across the query lib, CLI, and test crates; understanding this pattern is essential for safe dependency upgrades

• typst/typst — The core Typst language implementation; tinymist depends on and wraps this crate to provide IDE services
• astrale-sharp/typstfmt — Typst code formatter; tinymist integrates typstfmt as an optional formatter backend alongside typstyle
• Enter-tainer/typstyle — Alternative Typst formatter written in Rust; tinymist offers both typstfmt and typstyle as formatting providers
• microsoft/language-server-protocol — Specification for the LSP protocol that tinymist implements; referenced via tower-lsp and hyper dependencies
• rust-lang/rust-analyzer — Canonical LSP implementation for Rust; tinymist's architecture and feature set follow similar patterns (semantic analysis, code actions, multi-file support)

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 integration tests for tinymist-query analyzing library

The repo mentions tinymist-query as an 'analyzing library for Typst' in README.md, but there's no visible test directory structure for comprehensive integration tests. Given this is a language service with LSP capabilities, testing the query/analysis pipeline with real Typst documents would catch regressions and validate the core functionality that feeds into VSCode/Zed extensions.

• [ ] Create tests/integration directory structure for tinymist-query test cases
• [ ] Add 5-10 sample .typ files in tests/fixtures covering: imports, symbols, definitions, references, completions
• [ ] Write integration tests in tests/lib.rs that exercise tinymist-query against these fixtures
• [ ] Update ci.yml workflow to run integration tests in CI pipeline (currently only lints and builds)

Complete AGENTS.md with concrete AI/Copilot integration patterns

The repo has AGENTS.md and .github/copilot-instructions.md files, plus a .codex/skills directory with 7 skill definitions, but AGENTS.md appears to be a stub. This is a missed opportunity to document how AI agents (GitHub Copilot, Claude, etc.) should interact with the tinymist codebase. New contributors and AI tools need clear guidance on architecture patterns, testing approaches, and release workflows.

• [ ] Review existing .codex/skills/*.md files and .github/copilot-instructions.md to understand current guidance
• [ ] Document the tinymist architecture (query library → CLI → LSP server → editor extensions) in AGENTS.md
• [ ] Add sections on: recommended code patterns, how to add new LSP features, release process (linking to tinymist-release skill)
• [ ] Include explicit references to the skill definitions in .codex/skills/ so agents understand available tools

Add missing Zed language configuration and plugin scaffolding

The repo has .vscode/extensions.json and .vscode/launch.json for VSCode development, plus a Zed config in .zed/settings.json, but no actual Zed plugin workspace or build workflow. With Typst growing in popularity and Zed as a modern editor, adding proper Zed extension scaffolding would make the project more accessible to Zed users and mirror the VSCode setup's completeness.

• [ ] Create crates/tinymist-zed/ directory following the pattern of existing crates
• [ ] Add Cargo.toml for Zed plugin with proper zed-extension dependency
• [ ] Copy relevant language server configuration patterns from VSCode extension to Zed plugin
• [ ] Add GitHub Actions workflow in .github/workflows/build-zed.yml (similar to build-vscode.yml) to build and test Zed extension

• Add semantic highlighting rules for recently-added Typst 0.13+ syntax (e.g., new keyword forms). Start by examining crates/tinymist-query/src/semantic.rs and .github/workflows/ for examples of test patterns, then extend the token classification in the analyzer.
• Implement document-link support for @import directives in Typst. Currently document links handle image() and bibliography(); extend crates/tinymist/src/lsp/document_link.rs to parse and resolve import paths, validating they point to real Typst modules.
• Write missing integration tests in tests/ for the preview server's WebSocket communication. The preview feature is documented but lacks explicit e2e tests; see .github/workflows/ci-check-e2e.yml for the test harness and add cases for live-update scenarios.

The Tinymist codebase demonstrates generally good security practices with modern dependencies and TLS support. Key concerns include: (1) an incomplete Dockerfile that requires immediate fixing, (2) lack of explicit security configuration for the build cache system, and (3) broad dependency version ranges that could benefit from tighter constraints. The use of rustls-tls and modern async/await patterns is positive. The codebase follows good practices with workspace-level dependency management. Primary risks are in build infrastructure and potential transitive dependency vulnerabilities. Recommend: fixing the Dockerfile immediately, implementing cache integrity checks, establishing a regular audit routine with 'cargo audit', and documenting security-sensitive LSP handling procedures.

• Medium · Incomplete Docker Build File — Dockerfile (planner stage). The Dockerfile is incomplete and contains an unfinished command. The 'cargo +${RUST_VERSION} chef prepare --recipe-pat' command is truncated, which could indicate a broken build process or incomplete configuration. This may lead to unpredictable build behavior or security misconfigurations. Fix: Complete the truncated command and ensure all Dockerfile stages are properly defined. Verify the full build pipeline with 'cargo chef prepare --recipe-path'.
• Medium · Missing SCCACHE Security Configuration — Dockerfile (base stage). The Dockerfile uses sccache for caching but does not specify security parameters. The SCCACHE_DIR is world-writable and shared across builds with 'sharing=locked', but there are no integrity checks or authentication mechanisms configured for the cache. Fix: Implement cache validation, consider using signed cache artifacts, and restrict cache directory permissions. Document sccache security best practices.
• Low · Broad Dependency Version Ranges — Cargo.toml (workspace.dependencies). Several workspace dependencies use unconstrained version ranges (e.g., 'futures = "0.3"', 'tokio = "1.49.0"') without explicit upper bounds. While Cargo.lock provides reproducibility, this could allow unexpected breaking changes in minor/patch versions. Fix: Consider using tighter version constraints where stability is critical, or use 'cargo audit' regularly to monitor for vulnerable transitive dependencies.
• Low · HTTP/1.0 and WebSocket Dependencies — Cargo.toml (hyper, hyper-tungstenite, ezsockets dependencies). The codebase uses 'hyper-tungstenite' for WebSocket support over HTTP. Ensure proper TLS/HTTPS is enforced for all network communications, especially for LSP (Language Server Protocol) which handles sensitive code. Fix: Verify TLS is enforced for all network endpoints. Use reqwest with 'rustls-tls' (already configured) and ensure WebSocket connections use WSS (secure WebSocket).
• Low · Potential Code Generation Security — Cargo.toml (proc-macro2, quote, syn, wasm-bindgen dependencies). The codebase includes proc-macro dependencies (proc-macro2, quote, syn) and WASM bindings which perform code generation. If these consume untrusted input, they could potentially be exploited. Fix: Validate all inputs to macros. Avoid using proc-macros with untrusted or user-controlled code. Review macro expansion output for any unexpected behavior.
• Low · Windows System Dependencies Without Version Pins — Cargo.toml (windows-sys dependency). windows-sys = "0.61.2" is a broad dependency for Windows system calls. Ensure platform-specific code paths are audited, especially around file operations and process handling. Fix: Review all windows-sys usage for unsafe code blocks. Audit file permission handling and inter-process communication mechanisms.
• Info · Workspace Edition 2024 (Future Rust Edition) — Cargo.toml (edition and rust-version). The Cargo.toml specifies edition = "2024", which is very new and may not be fully stable. Combined with rust-version = "1.91", this is cutting-edge toolchain usage that could introduce unforeseen compatibility issues. Fix: Monitor Rust edition stability. Ensure all CI/CD pipelines test against the specified Rust version. Consider documenting MSRV (Minimum Supported Rust Version) separately.

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.