AllPrintings Audit

[carbohydrate]

Location of update needed

• Set sealedProduct: SealedProduct[] -> mark as optional Example: Set 4BB does not have this property
• Set decks: DeckSet[] -> optional Example: Set 2ED does not have this property, though lots of sets do not either
• DeckSet cards: CardSetDeck[] -> optional (probably reworked?) Example: decks in 10E do not have this property. I suspect this has been reworked into mainBoard, commander, sideBoard? With each of those consisting of CardSetDeck[]?
• DeckSet sealedProductUuids: string[] -> string[] | null; Example: Set 40K has 8 decks with this property as null
• SealedProductCard foil: boolean -> mark as optional Example: Set ELD has a SealedProduct -> contents -> card that is missing the foil property Card: Kenrith, the Returned King
• SealedProduct subtype: is currently optional, but needs null: string -> string | null Example: Set ONE has a SealedProduct with subtype null
• CardSet attractionLights?: string[] -> number[] Example Set UNF all 135 instances of this are number[] Maybe also need to be changed on CardAtomic and CardDeck? I'm not very familiar with what this is
• BoosterConfig boosters: BoosterPack[] -> Record<string, BoosterPack[]> Example: ONE has boosters object, with string keys ie: 'arena', 'collector', 'collector-sample', 'compleat', 'default', 'jumpstart', 'prerelease', 'set'
• BoosterSheet allowDuplicates: boolean -> mark as optional balanceColors: boolean -> mark as optional fixed: boolean -> mark as optional

This one I'm less sure about, could probably be accomplished a few different ways.

• BoosterPack contents: Record<string, number> -> Partial<Record<string, number>> BoosterConfig says boosters is BoosterPack[]. I think typescript is getting mad that some items in the array will have for example 'foilUncommon' defined, but others do not. I started down the path of doing something like this:

  contents: BoosterPackItem;
  export type BoosterPackItem = {
      basic?: number;
      common?: number;
      uncommon?: number;
      rare?: number;
      foilBasic?: number;
      foilCommon?: number;
      foilUncommon?: number;
      foilRare?: number;
      commonWithShowcase?: number;
      uncommonWithShowcase?: number;
      rareMythicWithShowcase?: number;
      dedicatedFoilDoubleMasters?: number;
      crypticSpires?: number;
      boxtopper?: number;
      a30Basic?: number;
      a30Common?: number;
      a30Uncommon?: number;
      a30Rare?: number;
      a30Retro?: number;
      a30RetroBasic?: number;
      prereleasePromo?: number;
      ...
  };

But decided just defining it as partial was better, as it the properties across the sets on these items are vastly different.

Additional context

I plan on working on a PR for this, just wanted a place to collect my notes. I also plan on working on audits on other files, just started here first.

Also, not 100% sure some of the suggestions are correct, specifically things that are optional, but then have a null value. Maybe the project should just omit those properties? I feel like I remember reading something about that is the project that generates the files, but maybe that is more work then it's worth? Let me know if anything should be done differently.

[staghouse]

Hey there, thanks for wanting to open an PR to fix these inaccuracies!

For the most part your thoughts are on point, anything that does not always return, should be marked as optional, and things that do always return should be marked as their type or null (traditionally this means that its not optional so if it was optional it should not have an optional badge). If you're finding that data is returning sometimes something, sometimes null and sometimes nothing then I would open a ticket in the mtgjson repo about that because that is historically not expected behavior. From a documentation standpoint data either returns sometimes something or sometimes nothing

The BoosterConfig issue you are running in to is a bit confusing for me. This is relatively new documentation and I may have got it wrong. Feel free to comment on the data structure returned from various sets and lets compare with what were seeing in the documentation.

As far as the the "Partial" issue, I think that would be just find to document it that way. I usually don't deal with partials so I had not thought of doing that. It also can get a bit "mysterious" to our non-TS friends but I cant think of another solution because like you said, these keys are all a bit scattered.