0.9.32

temporal-fmt v0.9.32

README quickstart was steering people into the expensive import path.
Every code sample under "Providing Temporal", "Formatting", and
"Parsing" imported format/parse from the bare temporal-fmt
entry point — which works, but the main entry re-exports everything
in the package, so a bundler pulls the whole graph in regardless of
which function you actually call. Measured with esbuild: ~27KB for
format alone via the subpath, versus ~68KB for the same single
function through the bare import. The subpath imports weren't new —
they'd existed for a while — they just weren't what the docs led
with.

Docs

• Formatting, Parsing, and Providing Temporal code samples now
  import from temporal-fmt/format and temporal-fmt/parse instead
  of the bare temporal-fmt entry.
• Added a "Get started" section right after Install: a four-line
  working example (one format() call, one parse() call, both via
  subpaths) before any discussion of package size or scope.
  Previously the fastest path to running code was scattered across
  three sections (Install → Providing Temporal → Formatting); now
  it's one.
• Added the measured 27KB/68KB numbers directly to the Subpath
  imports section, so the tree-shaking claim isn't just asserted —
  sideEffects: false is set in package.json, and this documents
  what it actually gets you.
• Added two bundlephobia badges (format and parse subpaths) next
  to the existing coverage badge, so subpath size is visible without
  digging into the docs.
• Rewrote the top-of-file description to match what the library
  actually does now (format + parse, real validation, locale
  support) instead of the original one-liner, which only mentioned
  formatting and predated the parse API entirely.

Changed

• package.json's description field was still the pre-parse
  wording ("Format Temporal.PlainDate/PlainDateTime/PlainTime/ ZonedDateTime objects using date-fns-style token strings.") —
  stale since parsing shipped. Updated to match the README's
  description.

NOTE: Also unrelated to this changelog — the 0.9.x lineup is probably going to last a lot longer than usual. You might expect 0.9.x to wrap up in a week like it used to, but I've slowed things down so I'm not telling people to upgrade over and over, rapidly. I'll release at a sensible pace instead. 0.9.x might run 2-3 weeks longer, and 0.8-lts will stay supported for that much longer too. When 0.10.x lands, 0.8-lts is still supported per the new policy in VERSIONS.md. Since 0.9.x is lasting much longer, 0.10.x will probably last longer too — maybe 3-4 weeks — since this library is mostly complete now and it's more about maintenance and fixes. So my rough estimate: 0.8-lts should keep getting security updates for another 1-2 months. In 0.9.4 i am expecting a big feature addition its one but its worth it before i can call it fully complete.