etree

etree brings a Python ElementTree-style API to Go for working with XML. It represents an XML document as a tree of Element and Token nodes, so programs can build documents from scratch, read them from files or streams, walk and mutate them in memory, and write them back out — all without hand-rolling loops over the standard library’s low-level encoding/xml token stream.

Beyond basic tree manipulation, etree adds a compact XPath-like query language (FindElement, FindElements, and precompiled Path objects via MustCompilePath) for selecting elements by tag, attribute value, or position, plus Go 1.23 range-over-func iterator variants for allocation-light traversal. It has zero third-party dependencies, ships configurable permissive parsing and depth-limited, sanitized output for safer handling of untrusted XML, and is actively maintained with regular releases.

What You Get

• A Document/Element API modeled on Python’s ElementTree for building and mutating XML trees programmatically
• A compact, XPath-like path query language for selecting elements by tag, attribute, position, or nested filter, with MustCompilePath to precompile and reuse a query
• Read/write support for files, byte slices, strings, or any io.Reader/io.Writer, with fine-grained control over permissive parsing and output formatting
• Built-in security hardening: a configurable ReadSettings.MaxDepth limit against XML depth-bomb attacks, plus sanitized text/CDATA/comment/ProcInst/directive output

Common Use Cases

• Parsing XML-based configuration files (build manifests, project files, legacy app configs) without generating Go structs for every schema
• Loading an XML document, mutating specific elements or attributes with path queries, and re-serializing it — e.g. rewriting build files or config exports from Go tooling
• Extracting fields from XML-based APIs, RSS/Atom feeds, or SOAP responses using FindElements-style queries
• One-off migration or reporting scripts that read structured XML exports from a legacy system and convert or summarize them

Under The Hood

Architecture etree is a single, tightly layered package built directly on the standard library’s encoding/xml. etree.go defines the core Document and Element/Token types and the readFrom/WriteTo methods that convert between the raw xml.Decoder token stream and the in-memory tree; path.go is a separate, self-contained query layer that compiles a path string into a reusable Path of segment/selector/filter interfaces (selectChildren, selectDescendants, filterAttr, filterPos, and friends) evaluated by a pather against an Element, connected to the tree layer only through Element’s FindElement/FindElementsPath* methods; helpers.go supplies shared low-level primitives — generic stack/queue types, an xmlPeekReader that buffers input to detect CDATA prefixes, and escapeString/sanitize* functions used by both the parser and the query layer for safe output. There is no dependency injection or external state; everything operates on an in-memory tree, so any change to Element’s child/attribute representation would ripple through both the path evaluator and the shared helpers.

Tech Stack The library is pure Go 1.23+ with zero third-party dependencies — go.mod declares only the module and Go version. It relies entirely on the standard library (encoding/xml, bufio, bytes, io, os, strings, slices, maps, and the Go 1.23 iter package for range-over-func iterators). There’s no build tooling beyond go build/go test; GitHub Actions CI compiles and tests against two Go versions (1.23 and 1.25.x) and runs CodeQL static analysis on every push and pull request. As a library, it has no deployment target of its own — it’s consumed via go get.

Code Quality The test suite is extensive: etree_test.go alone contains 45 table-driven test functions covering reading, writing, permissive parsing, CDATA handling, duplicate attributes, and entity resolution, plus dedicated path_test.go and example_test.go files, all using the standard testing package with shared document-construction helpers. Error handling is explicit throughout, via named sentinel errors (ErrXML, ErrMaxDepth, ErrPath) rather than panics, and every exported type and function carries a Go doc comment. Naming follows idiomatic Go conventions, and generics are used appropriately in helpers.go for the internal stack/queue types. CI enforces build and test success across Go versions plus CodeQL security scanning on every change, though there is no separate linter configuration beyond what go vet catches during build.

API Design The public API mirrors Python’s ElementTree closely, which gives Go developers coming from that ecosystem a familiar mental model, while its differentiator is a small, composable path-query engine: CompilePath/MustCompilePath produce a reusable Path object built from independent selector/filter interfaces, letting callers precompile a query once and reuse it across repeated searches for better performance than re-parsing a path string each time. Newer releases add Go 1.23 iterator-based Seq variants (ChildElementsSeq, SelectElementsSeq, FindElementsSeq, FindElementsPathSeq) alongside the original slice-returning methods for allocation-light traversal, and recent versions added defensive hardening — a configurable maximum tree depth and sanitized text/CDATA/comment/ProcInst/directive output — directly in response to a disclosed security issue. Getting started requires minimal boilerplate: NewDocument, ReadFromString/ReadFromFile, and a handful of Select/Find calls cover most use cases.