moon_config docs: clarify that post-processed Ast shapes differ between parse_moon_mod (deps object) and parse_moon_pkg (import array)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 1/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 82/100
- issue の種類
- ドキュメント
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
調査の方向性
moon_config README と parse_moon_mod および parse_moon_pkg のエントリーポイントから始め、moon.mod、moon.pkg、moon.work について文書化された後処理済みの形状を比較します。完了の条件は、ドキュメントで deps がモジュールからバージョンへのオブジェクトであり、import がパス/エイリアスオブジェクトの配列であることを、@version の動作も含めて明確に区別していることです。
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- MoonBit
- スター
- 35
- フォーク
- 10
- 平均マージ
- 7時間 25分
- マージ済み PR(30日)
- 16
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
moonbitlang/parser のほかの issue
-
impls_to_string drops mut and the colon of let mut対応中かも @Lfan-ke が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 87/100
moonbitlang/parser#217 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
moonbitlang/parser#202 ·
メンテナーはふだん 1 日以内に返信
-
CST lowering widens constraint-pattern locations through redundant parentheses再び着手できるかも @myfreess が 35 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
moonbitlang/parser#189 · コメント 1 件 · 担当者 2 名 ·
メンテナーはふだん 1 日以内に返信
-
Negative constant pattern locations exclude the minus sign in Handrolled and CST lowering再び着手できるかも @Yoorkin が 36 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンbug good first issue
moonbitlang/parser#188 · コメント 2 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
moonbitlang/parser の issue をすべて見る
似ている issue
-
documentation good first issue
難易度 1/5 1〜3時間 初心者へのやさしさ 84/100
sno-ai/sno-station#149 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
Git-Hospital/githealthcheck#60 ·
メンテナーはふだん 1 日以内に返信
-
docs pkg:core
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
pydantic/pydantic-ai#11929 ·
メンテナーはふだん 1 日以内に返信
-
[Skill Bug]: entra-agent-id: inaccurate blueprint permission inheritance and parent token sub claimオープンbug entra-agent-id
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
microsoft/GitHub-Copilot-for-Azure#3467 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 72/100
alvarotrigo/fullPage.js#4755 ·