This reference would allow someone to retrieve all the match games of a stage.

Especially in manager.get.stageData(), getting match games without stage_id would return every match game in the storage, which is overkill if there are multiple stages.

No need for other id references (group_id, round_id).

Some data won't be used after all.

• A group's name is currently used to know if it's a winner or loser bracket but that could be found with its number property
• All time data won't be used in either the manager or the viewer

TypeDoc supports a @defaultValue tag, which adds a default value in the generated documentation.

Add this everywhere.

The libraries from https://github.com/Drarig29/brackets-storage should not need to rely on brackets-manager's types.

Also, the CrudInterface that would be exported from brackets-model should be way simpler than the ones in the brackets-manager: it should not rely on DataTypes at all, and be "dumber".

This would keep the same amount of boilerplate type generics in storage implementations.

Hello, what is the algorithm to create Groups for Round objects? I found this types, but I have no idea how many Groups do I need to display tournament grid.

/**
 * A group of a stage.
 */
export interface Group {
    /** ID of the group. */
    id: number,

    /** ID of the parent stage. */
    stage_id: number,

    /** The number of the group in its stage. */
    number: number,
}

/**
 * A round of a group.
 */
export interface Round {
    /** ID of the round. */
    id: number,

    /** ID of the parent stage. */
    stage_id: number,

    /** ID of the parent group. */
    group_id: number,

    /** The number of the round in its group. */
    number: number,
}

When trying to create a Stage with Seeding the same way as in custom.spec.js#L16 TypeScripts errors.

This is due to the fact that a CustomParticipant also requires to have the Participant field, namingly id and tournament_id. I am not sure if this is intentional or not. Else I would propose something like this:

/**
 * The seeding for a stage.
 *
 * Each element represents a participant, which can be:
 * - A full object, with possibly extra fields.
 * - Its name.
 * - Its ID.
 * - Or a BYE: `null`.
 */
export type Seeding<Participant extends Partial<CustomParticipant> = CustomParticipant> = (Participant | string | number | null)[];

/**
 * Used to create a stage.
 */
export interface InputStage<Participant extends Partial<CustomParticipant> = Partial<CustomParticipant>> {
    /**
     * ID of the parent tournament.
     *
     * Used to determine the `number` property of a stage related to a tournament.
     */
    tournamentId: number;
    /** Name of the stage. */
    name: string;
    /** Type of stage. */
    type: StageType;
    /** The number of the stage in its tournament. Is determined if not given. */
    number?: number;
    /** Contains participants or `null` for BYEs. */
    seeding?: Seeding<Participant>;
    /** Contains optional settings specific to each stage type. */
    settings?: StageSettings;
}

participant should be able to hold at least an external_id if you want to reference to other systems and set more data based on it.
I would also like some additional fields like an image, a website and an identifier which marks the team as internal if you have tuniers and want your team to have a custom border or such.