Mistyped xtool.yml keys are silently ignored (e.g. entitlements instead of entitlementsPath)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 半日
- 初心者へのやさしさ
- 55/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- swift
- 領域
- build-system
調査の方向性
The schema is PackSchemaBase in Sources/PackLib/PackSchema.swift (lines 8-36), decoded with Yams around lines 73-75. Start by seeing how the decoder drops unknown keys, then compare the keys in the raw YAML document with the known property set. Done means an unrecognized key such as entitlements or icon produces an error or warning, and the issue's open question about error versus warning is settled with a maintainer.
索引モデルが issue の本文から書いたものです。
説明
Keys in xtool.yml that don't match a schema property are silently ignored. Because almost every schema property is optional, a single-character typo in a key name produces a valid-looking build with the wrong contents instead of an error.
PackSchemaBase (Sources/PackLib/PackSchema.swift:8-36) is decoded with plain Codable (via Yams at PackSchema.swift:73-75), so unknown keys are dropped by the decoder and the missing properties decode as nil.
Concrete cases:
entitlements:instead ofentitlementsPath:— the app is silently built with no entitlements at all. A push/network-extension app then installs but its features fail at runtime, and nothing at configure or build time indicates the file was never used.icon:instead oficonPath:— the app silently ships without its icon. Notably the value is validated (iconPath: icon.jpgfails with "iconPath should have a 'png' path extension",PackSchema.swift:56-60), but a mistyped key isn't.extension:instead ofextensions:— the extension is silently not built.bundleId:(lowercased) instead ofbundleID:— thenorgIDis missing too, and you get "Must specify either orgID or bundleID", which at least fails — but if the project also setsorgID, the explicit bundle-id intent is silently lost.
Related: when both bundleID and orgID are present, bundleID silently wins (PackSchema.swift:41-44); a warning would be reasonable there too.
The version key shows the other behavior is possible: an unsupported version errors out explicitly (PackSchema.swift:43-44), so being strict about unknown keys is consistent with the existing design.
Suggested direction
After decoding, diff the keys actually present in the YAML document against the known property set and throw (or at least warn) on unrecognized keys. YAMLDecoder won't do this on its own, but the raw document keys are easy to obtain with Yams' Yams.load(yaml:), and a short known-key list would catch most typos without much maintenance.
- 主要言語
- Swift
- スター
- 5.5k
- フォーク
- 163
- 平均マージ
- 18時間 29分
- マージ済み PR（30日）
- 27
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
xtool-org/xtool のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 63/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 51/100
xtool-org/xtool#401 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
メンテナーはふだん 1 日以内に返信
-
Error: exited(127)オープンbug
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
xtool-org/xtool#376 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[Feature Request] Add `xtool update` command for automatic CLI updates対応中かも @Madhav008 が 1 日前に担当しました。 オープンenhancement
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
xtool-org/xtool#365 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
xtool-org/xtool の issue をすべて見る
似ている issue
-
a:bug
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
vorssaint/vorssaint-utils#3527 ·
メンテナーはふだん 1 日以内に返信
-
bug iOS UI
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
devsoc-unsw/freerooms-mobile#278 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
rorkai/App-Store-Connect-CLI#3192 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
jellyfin/Swiftfin#2388 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信