build(deps-dev): bump @hebcal/learning from 6.9.5 to 6.9.8

[dependabot]

Bumps @hebcal/learning from 6.9.5 to 6.9.8.

Release notes

Sourced from @​hebcal/learning's releases.

v6.9.8

Computes the 929, Daf Yomi Yerushalmi and Tanakh Yomi cycles in constant time, and fixes a crash in the Yerushalmi Vilna cycle math.

No API changes. Signatures, exports and return shapes are unchanged.

Performance

These three calendars located the current cycle by walking forward from their epoch one cycle (or one day) at a time, so lookup cost grew without bound the further out the date. Per-lookup cost at year 2999:

calendar	before	after
calculate929	442 µs	0.2 µs
yerushalmiYomi (Vilna)	1589 µs	2.0 µs
tanakhYomi	195 µs	~1 µs

All three are now flat across the supported range rather than degrading with distance from the epoch.

929 cycles repeat on a fixed 1302-day period from cycle 2 onward: 929 chapters at five a week is 185 weeks plus four days, so the last chapter always falls at offset 1298 (a Wednesday) and the next cycle opens the following Sunday. Cycle 1's historical truncation at chapter 869 is preserved.

yerushalmiYomi uses the fact that each cycle consumes exactly numDapim reading days, so the position within a cycle is the running reading count modulo the cycle length. Skipped days are counted in constant time by exploiting that every Hebrew year holds exactly one Yom Kippur and one observed Tish'a B'Av.

tanakhYomi skip days depend on the holiday calendar and have no closed form, so this caches per-Hebrew-year prefix sums of reading days instead of re-running holiday lookups for every day in the year.

Bug fix

The Yerushalmi Vilna cycle walk could under-advance near a cycle boundary and yield a daf index one past the end of the shas, throwing Interal error, this code should be unreachable. This affected 2172-08-08 and 2420-09-27, and after the first occurrence the cycle was left permanently one daf behind. The replacement computes the index with a modulo, which cannot produce that value, so the fall-through is now genuinely unreachable rather than aspirationally so.

Behavior change

Vilna Yerushalmi readings after 2172-08-08 differ from v6.9.7. The new values are the correct ones; the old values descended from the crash described above. Everything before that date is unchanged, and no other calendar's output changes at all.

Verification

Output was diffed day by day against the v6.9.7 implementation: byte-identical across roughly 1.1 million days through year 2999 for 929, Yerushalmi Schottenstein and tanakhYomi, and for all 70,315 Vilna days from the 1980 epoch up to the crash date. Two new specs (test/calendarDifferential.spec.ts, test/cycleRollover.spec.ts) commit that coverage, deriving their expected checksums from the previous implementation.

v6.9.7

Build-only change: tsconfig.json now uses "module": "nodenext" / "moduleResolution": "nodenext".

No functional change. The emitted .js and .d.ts are byte-for-byte identical to the previous bundler-based build, and target (es2023) is untouched, so there is no change to the minimum Node or ECMAScript version.

This is a regression guard. moduleResolution: bundler accepts extensionless relative import specifiers, and tsc copies specifiers verbatim into the emitted .d.ts — so a bundler-built library can silently ship declarations that Node ESM / nodenext consumers cannot resolve, handing them any for every export instead of an error (because consumers typically set skipLibCheck). nodenext makes a missing .js extension a compile error here, so that defect cannot be published again.

v6.9.6

Ships the accumulated changes on main since v6.9.5 — the rollup-to-tsc build migration, the oxlint + prettier switch, and dependency updates (@hebcal/core ^6.9.1, @hebcal/hdate ^0.22.7).

Fixes TypeScript types for Node ESM / nodenext consumers. The v6.9.5 tarball was built before the tsc migration, so its .d.ts files used extensionless relative imports (from './DafPage'). Under "moduleResolution": "nodenext" those fail to resolve, and because consumers typically set skipLibCheck: true the failure was silent — every export degraded to any instead of raising an error. This release emits proper ./DafPage.js specifiers, so nodenext consumers get real types again.

No source or API changes; the fix was already on main and simply had not been published.

Commits

• 289b52f 6.9.8
• c79944c perf: compute 929, Yerushalmi and Tanakh Yomi cycles in O(1)
• 5db187f chore: update deps, run vitest non-interactively
• 7ff78e0 build: drop non-load-bearing tsconfig options
• 3851f1f chore: gitignore typedoc docs/ output
• c844896 6.9.7
• 90ab9a7 build: use module/moduleResolution nodenext
• 43393c2 6.9.6
• 9bbd8ef chore: update deps
• e8ea403 chore: update deps
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud