Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

moon_config docs: clarify that post-processed Ast shapes differ between parse_moon_mod (deps object) and parse_moon_pkg (import array)

Open Beginner friendly
#201 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Domain
documentation

Research direction

Start with the moon_config README and the parse_moon_mod and parse_moon_pkg entry points, comparing the documented post-processed shapes for moon.mod, moon.pkg, and moon.work. Done means the docs clearly distinguish deps as a module-to-version object from import as an array of path/alias objects, including the @version behavior.

Written by the indexing model from the issue text.

Description

Summary

moonbitlang/moon_config post-processes each manifest into different shapes, and the README examples show both without calling out the difference:

  • parse_moon_mod: the import { ... } block is rewritten into a top-level deps object — keys are module paths with any @version suffix stripped, values are the pinned versions:

    { "name": "example/app", "deps": { "moonbitlang/x": "0.4.6" } }
    
  • parse_moon_pkg: import stays an array of objects with path (and alias) fields:

    { "import": [{ "path": "moonbitlang/core/json", "alias": "json" }] }
    

Why it matters

Tooling built on parse_moon_mod naturally looks for an import array first (mirroring parse_moon_pkg's shape and the source syntax) and finds nothing — the imports now live under a differently-shaped deps key. The asymmetry (key rename import → deps, array → object, @version stripping) is easy to trip over since all three files (moon.mod / moon.pkg / moon.work) share the same DSL syntax.

Suggestion

A short note in the moon_config README (or the per-function docstrings) clarifying the per-file post-processed shapes — e.g. "moon.mod imports are merged into a deps object (module → version, @version stripped); moon.pkg keeps import as an array of {path, alias} objects".

Context: we build workspace release tooling on top of moon_config and hit exactly this while extracting member dependency graphs. Happy to send a docs PR if helpful.

Dominant language
MoonBit
Stars
35
Forks
10
Avg merge
7h 25m
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from moonbitlang/parser

All issues in moonbitlang/parser

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.