fix: reconcile flight aircraft/airline types with form input

[mhlas7]

Error

When saving a flight, the save util (src/lib/server/utils/flight.ts) builds a values object from form data and passes it as a CreateFlight. TypeScript rejected that at both saveFlightValues(values) call sites (the partial-date and day-precision branches). The error:

src/lib/server/utils/flight.ts(286,35): error TS2345: Argument of type
'{ from: {...}; ... 27 more ...; track: {...} | undefined }' is not
assignable to parameter of type 'CreateFlight'.
  ...
    Types of property 'aircraft' are incompatible.
      Type '{ id: number | null; name: string; icao: string | null; } | null'
        is not assignable to type
      '{ id: number; name: string; icao: string | null; sourceId: string | null; } | null'.
        Property 'sourceId' is missing in type
        '{ id: number | null; name: string; icao: string | null; }' but required in type
        '{ id: number; name: string; icao: string | null; sourceId: string | null; }'.

The issue behind it

CreateFlight typed its aircraft/airline as the full DB records (Aircraft = Selectable<aircraft>, Airline = Selectable<airline>), which require a non-null id and a sourceId. But the flight form produces looser objects (from aircraftSchema / airlineSchema):

• id is number | null — a not-yet-created aircraft/airline has a null id
• aircraftSchema has no sourceId (and airlineSchema's sourceId / iconPath are optional)

The error message only names sourceId because TypeScript reports the first incompatible property, but there are really two gaps — the missing sourceId and the id: number | null → number mismatch — affecting both aircraft and airline.

Key facts that shaped the fix:

• The schemas can't be tightened (make id non-null), because they're shared with the
  aircraft/airline create forms where a null id is valid.
• Downstream, only .id is ever read off these fields (src/lib/db/queries.ts —
  aircraftId / airlineId); nothing uses name / icao / sourceId.
• Importers pass full records or null, so they still satisfy a loosened type.

The fix (src/lib/db/types.ts)

Loosen the two CreateFlight fields to "an Aircraft/Airline, but with a nullable id and without the fields the form omits" — derived from the DB types so name / icao / iata stay in sync:

type FlightAircraftInput = Omit<Aircraft, 'id' | 'sourceId'> & { id: number | null };
type FlightAirlineInput  = Omit<Airline,  'id' | 'sourceId' | 'iconPath'> & { id: number | null };

export type CreateFlight = FlightRecord & {
  ...
  aircraft: FlightAircraftInput | null;   // was: Aircraft | null
  airline:  FlightAirlineInput  | null;   // was: Airline  | null
  ...
};

Both the form's schema outputs and full Aircraft/Airline records assign to these, and .id still types as number | null — a types-only change with no runtime behavior difference. (Airline also drops iconPath because Omit<Airline, 'id' | 'sourceId'> would otherwise keep it required, while the form has it optional.)

Verified: the TS2345 … not assignable to 'CreateFlight' errors in flight.ts and the importers are gone; prettier clean. Single-file change on fix/aircraft-airline-createflight-type (off current origin/main).

Note

Fix aircraft and airline types in CreateFlight to accept nullable IDs for unsaved entities

Introduces FlightAircraftInput and FlightAirlineInput type aliases in types.ts to represent aircraft and airline data as it arrives from form input. Both types omit fields not present in form input (e.g. sourceId, iconPath) and reintroduce id as nullable to handle not-yet-persisted entities. The CreateFlight type is updated to use these input-focused types instead of the full Aircraft and Airline types.

^{Macroscope summarized 71b7523.}

[github-actions]

Label error. Requires exactly 1 of: changelog:.*. Found: Web

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[johanohly]

Thanks, went ahead and fixed all the type errors in the app instead though, including this one. Honestly the main reason I never did it previously was because svelte-check would OOM every time I ran it. Figured out it was a bug in the validation library we use (zod), so after updating it I was able to run it and fix all the errors.

[mhlas7]

I got svelte-check running but I had to manually set the memory heap to 10 Gb of RAM otherwise it would OOM. Glad these are all fixed!