tree-sitter-ruby

tree-sitter-ruby is the official Ruby language grammar for tree-sitter, the incremental parsing framework used by editors and developer tools to build fast, error-tolerant syntax trees. It defines Ruby’s grammar in grammar.js, which tree-sitter compiles into a generated C parser that handles Ruby’s dynamic, delimiter-heavy syntax including blocks, heredocs, string interpolation, and pattern matching.

The repository ships first-party bindings for Rust, Node.js, Python, Go, and Swift, so the same grammar can be embedded in editors, linters, or static-analysis tools written in any of those ecosystems. It also includes highlight and structural queries (queries/) used by editors like Neovim, Zed, and Helix to drive syntax highlighting and code navigation for Ruby source files.

What You Get

• A complete Ruby grammar (grammar.js) covering declarations, expressions, control flow, blocks, heredocs, and pattern matching
• A generated, dependency-free C parser compiled from the grammar for use by the tree-sitter runtime
• First-party language bindings for Rust, Node.js, Python, Go, and Swift
• Highlight and tag queries (queries/) that editors use for syntax highlighting, code folding, and symbol navigation
• A corpus-based test suite (test/corpus) covering control flow, pattern matching, literals, and line-ending edge cases

Common Use Cases

• Powering syntax highlighting and code navigation for Ruby files in editors like Neovim, Zed, Helix, or Atom
• Building a static analysis, linting, or Rubocop-style tool that needs an accurate, incrementally-updatable Ruby syntax tree
• Implementing structural code search or refactoring tooling that queries Ruby source via tree-sitter’s query language
• Embedding a Ruby parser in a Rust, Python, Go, or Node.js application via the official language bindings

Under The Hood

Architecture - The grammar is authored once in grammar.js (roughly 1,300 lines) using tree-sitter’s JavaScript DSL, then compiled offline into a generated C parser plus node-types.json/grammar.json metadata describing the resulting syntax tree shape. Each bindings/<language> directory (rust, node, python, go, swift, c) is a thin wrapper linking against this generated C parser and exposing it through that language’s native FFI conventions — the Rust binding compiles the generated C source via a cc-based build script and links through the tree-sitter-language crate.

Tech Stack - The Rust crate has a minimal footprint: tree-sitter-language as its only runtime dependency and cc as a build-time dependency, with tree-sitter needed only as a dev-dependency for tests. The repository spans five language-ecosystem packagings (Cargo, npm, PyPI, Go modules, Swift Package Manager) all built from the same shared grammar.js source, with the primary implementation language being generated C.

Code Quality - Correctness is validated through a corpus-based test suite (test/corpus) with dedicated files for control flow, pattern matching, literals, comments, and line-ending edge cases (including a file specifically for lone-CR line endings, a known Ruby-parsing gotcha) — the kind of targeted regression coverage that matters most for grammar development. As with other tree-sitter grammars, the generated parser source isn’t hand-edited directly; all real changes flow through grammar.js and get regenerated.

API Design - Consumers interact with the crate through tree-sitter’s standard Language/Parser API (tree_sitter_ruby::LANGUAGE), consistent with every other tree-sitter grammar crate, so an application already using tree-sitter for one language can add Ruby support with the same integration pattern it already knows.