[bug] support `null`ing out extended tsconfig.json properties

[mjames-c]

simple repro:

// tsconfig.base.json
{
  "compilerOptions": {
    "types": []
  },
}

// tsconfig.json
{
  "compilerOptions": {
    "types": null
  },
  "extends": "./tsconfig.base.json"
}

then run the below and note that compilerOptions.types is still set to the empty array, [].

$ built/local/tsgo -p path/to/tsconfig.json -showConfig
{
  ...
  "types": [],
  ...
}

[jakebailey]

This is a challenge in the Go code since we don't have two kinds of null anymore; I think we should have some sort of "unresolved" compiler options we use during load, which we then finalize into the final settings that don't need null.

[LukeAbby]

There's roughly two options:

1. Unmarshal to a field to json.RawMessage or the entire config to map[string]interface{}. This seems annoying as now you have to manually implement the decoding.
2. Add a type like Maybe[Value any] type for null-aware deserialization, e.g.

type Maybe[Value any] struct {
    value Value
    wasSet bool
    wasNull bool
}

var _ json.Unmarshaler = &Maybe[any]{}

func (*m Maybe[Value]) UnmarshalJSON(buf []byte) error {
    m.wasSet = true

    if string(buf) == "null" {
        m.wasNull = true
        return nil
    }

    err = json.Unmarshal(buf, &m.value)
    return err
}

[jakebailey]

Note that tsconfig parsing operates on SourceFiles, so never actually interacts with Go's json package. This is all stuff we'd need to implement ourselves differently.

[LukeAbby]

Oh, my bad! Sorry for the unhelpful help.