js-symbol-tree is a JavaScript library that turns a collection of objects into an efficient tree or linked list using an ES6 Symbol for storing metadata on the objects themselves. It provides constant-time operations for insertion, deletion, and DOM-like navigation such as firstChild, nextSibling, parent, and removal, making it useful as a backing data structure for DOM-style trees in Node.js and modern browsers.
Project status
- Maintenance status: Evidence suggests quiet, in-maintenance mode. The last upstream push was 2020-04-25, and the most recent detailed update notes provided are from v3.2.4 and v3.2.3 in 2019.
- Update cadence: Historically released, but in the current period there is multi-year inactivity relative to today (2026-06-11), with updates occurring years apart rather than on a regular schedule.
AI summary generated
Recent updates
v3.2.4
v3.2.4 primarily updates documentation artifacts (README API docs) and bumps a development tooling dependency. No runtime/library logic changes are evident from the provided diff; changes are limited to docs and the package manifest/version.
v3.2.3
v3.2.3 contains a small internal change to SymbolTree node removal behavior, plus test coverage for cache invalidation. The release notes are missing, so the published changes cannot be verified against documentation.
Breakingv3.2.2
Release v3.2.2 was published on 2017-02-11, but no release notes were provided by the publisher. Without notes or accompanying changelog details, there is insufficient information to identify specific new features, bug fixes, or breaking changes.
v3.2.0
v3.2.0 primarily modernizes the development tooling by replacing jscs and jshint with eslint, and it reduces what gets published to npm. The actual library changes shown in the diff are minimal, mostly documentation formatting, lint configuration, and style-only edits, with at most a trivial internal refactor in one traversal method.
v3.1.4
Release v3.1.4 is labeled as a Babel compatibility fix. However, the diff shows mostly documentation and test updates (README/api.md and JSDoc complexity annotations), plus minor internal code variable renaming in SymbolTree.js, with no clear public API or behavior change shown.
v3.1.2
v3.1.2 is a small maintenance release that claims to fix a bug that could corrupt the index cache. The diff shows a targeted change in SymbolTree's cached index handling plus a small test addition to cover cache stability after child mutations.
v3.1.0
v3.1.0 bumps the package version and makes a small change to the module API surface. The code change adds an export for TreePosition via the SymbolTree class.
Featuresv3.0.0
This release (v3.0.0) renames the SymbolTree sibling-iterator API from prevSiblingsIterator to previousSiblingsIterator. The change is applied in the core implementation, public API docs, and the corresponding test.
Breakingv2.0.0
v2.0.0 introduces a rewritten API surface for symbol-tree, centered on renamed methods and adjusted argument conventions. The implementation changes are broad, touching core node properties, sibling/child navigation, insertion helpers, and iteration utilities.
BreakingFeaturesv1.5.0
v1.5.0 introduces the ability to iterate symbol-tree nodes in reverse order for both child iteration and subtree (descendants) iteration. The release notes section is empty, so these changes are not described there.
Featuresv1.4.0
Release v1.4.0 (from v1.3.1) adds new sibling-iteration capabilities to SymbolTree, specifically iterators for previous and next siblings. Release notes were not provided by the publisher, so the changes are inferred entirely from the code diff, documentation updates, and new tests.
Featuresv1.3.1
v1.3.1 introduces a new tree-position comparison API (SymbolTree.compareTreePosition) and adds an internal position/constant module (TreePosition). It also changes the internal index-caching strategy to warm cached child indices during traversal and to remember how far child index caching has been computed.
Featuresv1.2.0
This release (v1.20, version 1.2.0) does not include any publisher-provided release notes, so the developer-facing changes cannot be determined from the provided information. To assess upgrade impact, you will need to compare the tag changes (v1.20) against the previous version in the repository.