#moon_shadow

let info = @moon_shadow.current()
println(info.name)                          // "PaiGack/moon_shadow"
println(info.version)                       // "0.1.0"
println(info.long_version())                // "PaiGack/moon_shadow@0.1.0"
println(info.dep("moonbitlang/moon_config")) // Some(...)

#Using it in your own module

1. Depend on PaiGack/moon_shadow, with the library in a moon.work beside your module — the setup moon_shadow_example/ shows:

moon add PaiGack/moon_shadow

2. Run moon check. The init rule in the library's shadow/moon.pkg discovers your module — it looks for the moon.mod files near the library that import it — and writes everything the manual setup used to ask for:

moon_shadow: initialized /path/to/your/module
  moon.work: added member ..
  shadow/moon.pkg: created
  shadow/generated.mbt: created
  moon.pkg: added import PaiGack/moon_shadow
  moon.pkg: added overrides your/module/shadow

3. Run moon check once more and you are done. From then on moon check / moon run regenerate shadow/generated.mbt whenever moon.mod changes, and @moon_shadow.current() reports your module's metadata.

moon run --target js --target-dir _build/init <path-to>/moon_shadow/init -- /path/to/your/module

#What the scaffold contains

import {
  "PaiGack/moon_shadow/core",
}

virtual(implement: "PaiGack/moon_shadow/shadow")

rule(
  name: "gen",
  command: "moon run --target js --target-dir _build/gen <path-to>/moon_shadow/gen/main.mbt -- $input $output",
)
dev_build(rule: "gen", input: "../moon.mod", output: "generated.mbt")

options(
  overrides: [ "your/module/shadow" ],
)

#How it works

moon.mod --(gen rule)--> shadow/generated.mbt --(compile)--> current()

consumer moon.mod --(init rule)--> shadow/ scaffold + overrides in moon.pkg

pub fn module_info() -> @core.ModuleInfo

#API

#Repo layout

core/                ModuleInfo / Dependency, `moon_config` parsing, codegen
gen/                 the generator executable, `moon.mod` -> implementation
init/                the one-command setup, writes a consumer's shadow scaffold
shadow/              virtual package + its generated default, gen + init rules
moon_shadow.mbt      the public API: current()
moon_shadow_example/ a consumer module, with its own moon.work workspace

#Behaviour worth knowing

• A moon.pkg-declared virtual package must expose functions, not values. moon type-checks a virtual package's implementations against pkg.mbti, and a pub let of a type from another package fails that check even though it compiles in the implementing package. Hence module_info() rather than module_info.
• current() describes whoever provided the implementation, not whoever called it. moon_shadow_example/ shows both sides: without an override you get the library's baked-in values, with one you get your own.
• A module cannot override its own virtual package. That is why the example is a separate module rather than another package inside moon_shadow.
• A dependency from the registry never runs build rules. MoonBit skips a dependency's pre-build steps when it is consumed from .mooncakes, so published implementations are committed: after editing moon.mod, run moon check and commit the result. CI fails with a diff if you forget.
• A workspace member's rules do run. A library listed in a consumer's moon.work is built as part of that consumer's build, rules included — which is what init relies on to set a consumer up unattended, and why the moon.work setup above is the supported one.
• Escapes are decoded once. moon_config returns string literals in their raw source form ("a \"b\"" yields a \"b\"), so core unescapes before re-emitting them; otherwise every regeneration would double the backslashes.