content_version

Per-path content-version counters — a cheap, synchronous "has this file changed?" token. An assetType behavior memoizes its parse in the ref's runtime keyed by the counter get(path) returned when it parsed, then serves every later read as an integer compare instead of re-reading and re-parsing the file.

Why it exists

A .data() behavior that re-reads and re-parses its source on every call is pure overhead when the file hasn't changed. This module gives it a version token to gate the rebuild on:

• get(path) when the parse ran, stored alongside the parsed value.
• On every later call, compare get(path) to the stored value — equal means the cache is still valid (no vfs.read, no parse); a bump means rebuild.

Exports

• M.get(path: string) -> number — the path's current version counter (0 if never written this VM).
• M.bump(path: string) — bump path's counter, invalidating every reader memoized against its previous value. Content code rarely calls this directly.

What bumps a counter

Two write surfaces feed it, so the token reflects a change no matter where it originated:

• vfs.write / vfs.move / vfs.remove bump synchronously, in the same call — so a script that writes a file and reads it back in the same tick sees the new content immediately (the asset-change onChange dispatch fires a frame later, too late for a same-tick read).
• the generic asset-change dispatcher bumps on every source write it routes, including peer-synced and engine-originated writes that never pass through the Luau vfs.* surface — with the engine's normalized path, the canonical form a reader keys on.

Per-path, not a global epoch

Counters are per path, not one global epoch. The per-frame dirty-entity writer churns scene-dirty paths every frame during play; a global epoch would let that churn invalidate every unrelated cache. Per-path isolation means only a change to the file a reader depends on rebuilds it.

The counters are held once for the process (__contentVersion), so a single store is shared across every VM and every copy of this module that a require-cache reset (vfs.reload) might create. A bumper and a reader that landed on different VMs or module copies read the same number: a write made in a worker VM, the engine thread's dispatch of it, and a write made on the engine thread advance one counter.