You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/tempo/CHANGELOG.md
+16Lines changed: 16 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,22 @@ All notable changes to this project will be documented in this file.
4
4
5
5
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
6
6
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
7
+
8
+
## [2.9.0] - 2026-05-06
9
+
10
+
### Added
11
+
-**Centralized Alias Architecture**: Finalized the migration to a unified `AliasEngine`. All event and period aliases are now managed through a centralized registry, providing a single source of truth across global and local contexts.
12
+
-**Rich Alias Results**: Alias resolution now returns a structured `AliasResult` object containing exhaustive metadata, including the source (global/local), type (Event/Period), and specific resolution flags.
13
+
-**Hardened Clock Snapping**: Standardized the resolution path for clock-like aliases (e.g. `8:00`). The engine now ensures absolute sub-second precision clearing (milliseconds, microseconds, and nanoseconds) when snapping to a time-string alias.
14
+
-**Optimized Lifecycle Monitoring**: Implemented a version counter in the `AliasEngine`. Mutation operations now trigger a version increment, allowing `Tempo` instances to efficiently detect registry changes and rebuild internal regex patterns without expensive deep-cloning.
15
+
16
+
### Changed
17
+
-**Parser Context Consolidation**: Extracted the "host" facade construction from the main parsing loop into a dedicated `getResolutionContext` helper, improving maintainability and reducing Parser complexity.
18
+
-**Decoupled Term Registration**: Refactored `Tempo.extend` and term-based alias registration to bypass legacy raw registries, while maintaining backward compatibility via a mirrored metadata view.
19
+
20
+
### Fixed
21
+
-**Documentation Server Stability**: Resolved VitePress 404 errors by correcting the `srcDir` configuration and implemented `srcExclude` to prevent build failures from dead links in non-documentation folders.
Copy file name to clipboardExpand all lines: packages/tempo/doc/architecture.md
+13-1Lines changed: 13 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -130,7 +130,19 @@ The **Guarded-Lazy** strategy ensures that even with hundreds of custom plugins,
130
130
1.**Longest-Token Matching**: To prevent partial matching (e.g., matching `qtr` inside `quarter`), the guard uses a "Scan-and-Consume" loop that prioritizes the longest available token.
131
131
2.**Unified Wordlist**: The guard automatically ingests all registered Terms, Timezones, Month names, and Custom Events into a single high-speed lookup Set.
132
132
3.**High-Speed Gatekeeper**: By avoiding complex backtracking regexes, the gatekeeper provides predictable $O(1)$ performance even as the plugin list grows.
133
-
4.**Auto-Lazy**: Valid inputs that pass the guard automatically switch the instance to `mode: 'defer'`, deferring the full $O(N)$ parse work until a property is actually read.
133
+
4.**Versioned Registry (v2.9.0)**: To avoid redundant wordlist rebuilding, the Guard now monitors a `#version` counter on the alias registry. The wordlist is only rebuilt when a mutation actually occurs.
134
+
5.**Auto-Lazy**: Valid inputs that pass the guard automatically switch the instance to `mode: 'defer'`, deferring the full $O(N)$ parse work until a property is actually read.
135
+
136
+
---
137
+
138
+
## 🧩 Centralized Alias Management (v2.9.0)
139
+
As of **v2.9.0**, Tempo has consolidated all Event and Period alias logic into a dedicated **`AliasEngine`**.
140
+
141
+
### How it works:
142
+
-**Hierarchical Registry**: Aliases are managed in a prototype-aware chain. A local `Tempo` instance can have its own private aliases that shadow global ones, all while sharing the same underlying resolution logic.
143
+
-**Rich Metadata**: Every resolution returns a structured `AliasResult`, providing the Parser with immediate knowledge of the alias's origin (global vs local), type, and clock-snapping requirements.
144
+
-**Clock Snapping**: Time-based aliases (e.g. `8:00`) are automatically "snapped" to absolute precision, clearing sub-second drift (ms, us, ns) during the resolution phase.
145
+
-**Decoupled Registration**: By moving away from legacy raw objects, the registry is now protected against accidental mutation and supports efficient, version-aware monitoring.
134
146
135
147
### 📈 Validation & Performance
136
148
The efficiency of the Master Guard and the success of the Zero-Cost objective have been validated via local benchmarking:
Copy file name to clipboardExpand all lines: packages/tempo/doc/releases/v2.x.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,23 @@
1
1
# 📜 Version 2.x History
2
2
3
3
4
+
## [v2.9.0] - 2026-05-06
5
+
### 🏗️ Alias Architecture Stabilization
6
+
-**Unified Alias Engine**: Completed the architectural migration to the `AliasEngine`, centralizing all registration and resolution logic for Events and Periods.
7
+
-**Rich Metadata Results**: Enhanced the resolution engine to return structured `AliasResult` objects, providing better traceability and granular control over alias-driven parses.
8
+
-**Hardened Clock Snapping**: Finalized the standardization of clock-like alias resolution, ensuring consistent sub-second precision clearing for all static and functional time aliases.
9
+
-**Performance Optimized Monitoring**: Introduced a lightweight version-tracking system to detect registry mutations, enabling `O(1)` change detection during the Tempo lifecycle.
10
+
11
+
### ⚙️ Parser & Registry Refinement
12
+
-**Consolidated Host Context**: Modularized the construction of the functional alias "pseudo-Tempo" context, improving separation of concerns in the parsing pipeline.
13
+
-**Legacy Decoupling**: Successfully decoupled term-based alias registration from internal raw objects, moving toward a more encapsulated and secure registry design.
14
+
15
+
### 📚 Documentation Fixes
16
+
-**VitePress 404 Patch**: Corrected root directory resolution to fix "404 Not Found" errors on the landing page.
17
+
-**Build Resilience**: Implemented targeted folder exclusion to prevent build-time dead-link errors in non-public directories.
18
+
19
+
---
20
+
4
21
## [v2.8.0] - 2026-04-30
5
22
### 🚨 Immutability System Refined
6
23
- The project evaluated mutation-throwing Proxies for all immutable objects, but reverted to using `Object.freeze` for stability and compatibility.
Copy file name to clipboardExpand all lines: packages/tempo/doc/tempo.parse.md
+31-1Lines changed: 31 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -111,7 +111,37 @@ Tempo.init({
111
111
const t =newTempo('party');
112
112
```
113
113
114
+
### 🧠 Functional Alias Context
115
+
When you use a function as an alias value, Tempo provides a powerful **Resolution Context** (the `this` binding). This context mimics a lightweight Tempo instance, allowing you to perform relative date math during resolution.
116
+
117
+
Available methods in the context:
118
+
***`this.add(duration)`**: Add a duration to the current anchor.
119
+
***`this.subtract(duration)`**: Subtract a duration.
120
+
***`this.with(values)`**: Set specific fields (year, month, day, etc.).
121
+
***`this.set(input)`**: Recursively parse another string or value relative to the anchor.
122
+
***`this.toNow()`**: Get the current system time.
123
+
***`this.toDateTime()`**: Get the current anchor as a native `Temporal.ZonedDateTime`.
124
+
***`this.hh`, `this.mi`, `this.ss`**: Accessors for current time units.
// Resolve "meeting" to 2 hours after whatever was just parsed
135
+
'meeting': function() {
136
+
returnthis.add({ hours: 2 });
137
+
}
138
+
}
139
+
});
140
+
```
141
+
114
142
---
115
143
116
144
## 🛡️ Performance: The Master Guard
117
-
Tempo uses a "Scan-and-Consume" engine called the **Master Guard**. This allows it to check your input string against dozens of patterns (weekdays, months, custom events) in a single pass, ensuring that parsing remains $O(1)$ relative to the number of plugins you have active.
145
+
Tempo uses a "Scan-and-Consume" engine called the **Master Guard**. This allows it to check your input string against dozens of patterns (weekdays, months, custom events) in a single pass.
146
+
147
+
In version **2.9.0**, the Master Guard has been optimized with a **Versioned Registry**. The engine now tracks a `#version` counter on the alias registry, ensuring that the guard's pattern list is only rebuilt when a mutation actually occurs. This provides near-instant validation for high-volume parsing tasks.
Maps the current date to the appropriate meteorological season.
57
-
Hemisphere-aware (northern / southern boundaries differ), and the full `season` scope additionally includes the corresponding **Chinese season** for the date.
A `Range` object must include a `key` and any subset of the date-time fields below.
211
208
`getTermRange` sorts ranges in descending chronological order and returns the **first range whose boundary the instance has reached or passed**.
212
209
210
+
### 🔄 Sync to Alias Engine
211
+
When a term plugin defines `ranges` with string-based `key` values, Tempo automatically synchronizes these keys with the internal **Alias Engine**.
212
+
213
+
***Period Scopes**: Ranges defined in a `period` scope (like `midnight` or `morning`) are registered as **Period Aliases**.
214
+
***Event Scopes**: Ranges defined in an `event` scope are registered as **Event Aliases**.
215
+
216
+
This synchronization happens during `Tempo.extend()` and `Tempo.init()`, ensuring that any named range boundaries are immediately available for use in the natural-language parsing engine. For example, if you define a custom term with a range key `"bedtime"`, you can immediately create a new instance using `new Tempo('bedtime')`.
217
+
213
218
```ts
214
219
typeRange= {
215
220
key:PropertyKey; // identifier returned when keyOnly = true
0 commit comments