moon_config docs: clarify that post-processed Ast shapes differ between parse_moon_mod (deps object) and parse_moon_pkg (import array)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 85/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- documentation
Research direction
Start with the moon_config README and the per-function docstrings mentioned in the issue. Document the different post-processed shapes for parse_moon_mod and parse_moon_pkg, including deps versus import, object versus array, and @version stripping; done means both examples make the distinction explicit.
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: theimport { ... }block is rewritten into a top-leveldepsobject — keys are module paths with any@versionsuffix stripped, values are the pinned versions:{ "name": "example/app", "deps": { "moonbitlang/x": "0.4.6" } } -
parse_moon_pkg:importstays an array of objects withpath(andalias) 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
- 8h 2m
- Merged PRs (30d)
- 17
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from moonbitlang/parser
-
Difficulty 1/5 1-3 hours Newbie friendliness 82/100
moonbitlang/parser#201 ·
Maintainers usually reply within 1 day
-
CST lowering widens constraint-pattern locations through redundant parenthesesMay be free again @myfreess claimed this 36 days ago, and no pull request is open. Open
moonbitlang/parser#189 · 1 comment · 2 assignees ·
Maintainers usually reply within 1 day
-
Negative constant pattern locations exclude the minus sign in Handrolled and CST loweringMay be free again @Yoorkin claimed this 36 days ago, and no pull request is open. Openbug good first issue
moonbitlang/parser#188 · 2 comments · 1 assignee ·
Maintainers usually reply within 1 day
All issues in moonbitlang/parser
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
aws-samples/sample-per-model-bedrock#638 ·
Maintainers usually reply within 1 day
-
bug documentation
Difficulty 1/5 Under an hour Newbie friendliness 80/100
awslabs/visual-asset-management-system#936 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
14.3.x
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
good first issue help wanted r-docs
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
servo/rust-smallvec#824 ·
Maintainers usually reply within 1 day