Feature: Add support for types from serde_json

[NyxCode]

Goal

This PR adds support for types from serde_json: serde_json::Value, serde_json::Number and serde_json::Map.

Most common (and most tricky) of them is serde_json::Value.
Right now, the easiest way to get a struct containing a Value to implement TS is to slap a #[ts(type = "any")] on the fields.
However, that's not great, since a JSON object is actually not any.

If a user wanted to get a more precise type for it, they might have tried this:

#[derive(TS)]
#[ts(untagged, export_to = "serde_json/")]
enum TsJsonValue {
    String(String),
    Number(i32),
    Array(Vec<TsJsonValue>),
    Object(HashMap<String, TsJsonValue>),
}

#[derive(TS)]
struct SomeStruct {
    #[ts(as = "TsJsonValue")]
    field: serde_json::Value,
}

Interestingly, tsc doesn't want to compile TsJsonValue.ts. This is one of the (rare) cases where Record<string, TsJsonValue>, which is what we generate, doesn't work, but { [key: string]: TsJsonValue } would.

Changes

In essence, all this PR does is the code above, except that TS had to be implemented manually for serde_json::Value.

Unlike all previous ..-impl features, this one actually exposes an exportable type, JsonValue.
Before, all impls were simply and just generated e.g number. The one for serde_json::Value, however, is recursive, and therefore needs an actual name.

If a user exports a struct containing serde_json::Value, JsonValue.ts will get exported to ./serde_json/.

Alternatives

We could, instead of merging this now, first explore if generating { [key: K]: V } for maps makes sense.
Then, this PR would not require the manual TS implementation (If we made #[derive(TS)] work inside ts_rs, which it currently does not).
(#134)

Checklist

• I have followed the steps listed in the Contributing guide.
• If necessary, I have added documentation related to the changes made.
• I have added or updated the tests related to the changes made.

[NyxCode]

The impl is pretty much exactly like the one generated by

#[derive(TS)]
#[ts(untagged, export_to = "serde_json/")]
enum JsonValue {
    String(String),
    Number(i32),
    Array(Vec<TsJsonValue>),
    Object(HashMap<String, JsonValue>),
}

with the exception that it uses { [key: string]: JsonValue } instead of Record<string, JsonValue>.

[NyxCode]

I just realized that what would work is

#[derive(TS)]
#[ts(untagged, export_to = "serde_json/")]
enum TsJsonValue {
    String(String),
    Number(i32),
    Array(Vec<TsJsonValue>),
    Object(#[ts(type = "{ [key: string]: TsJsonValue }")] ()),
}

since the Array variant already creates a dependency on TsJsonValue.

We can't do that in ts_rs right now, however - see the comment on the manual implementation.

[escritorio-gustavo]

I really like these changes, if you want I can push some commits to #274 so we can merge it faster as well as create a PR for #134

[NyxCode]

I've merged #277 and #274 into this branch to see how that'd look like.
However, now imports don't always work, and I'm not sure yet why.

[NyxCode]

Nevermind - impl_shadow did not generate fn output_path(). Never needed it before, because all types we shadowed weren't exportable.

[escritorio-gustavo]

Awesome! Can this PR be merged or is there anything else you'd still like to do?

[NyxCode]

Last thing I'm unsure about here: Is Value to vague? We currently don't/can't deal with name collisions, so maybe JsonValue might be a better name.

[escritorio-gustavo]

JsonValue would be a better name, but given the use of #[ts(export_to = "serde_json/")] I think a name collision is really unlikely

[NyxCode]

Alright, lemme quickly rename it. The name collision i'm more worried about is

import type { Value } from "../serde_json/Value";
import type { Value } from "../somewhere/else/Value";

[escritorio-gustavo]

Oh, I see. I thought you were worried about the file getting overwritten

[NyxCode]

Alright, let's get this merged!
I'm super happy with how #277 and #274 came together.
And we're finally getting some use out of the effort we put in to export paths and recusrive exports.

[NyxCode]

I guess this demonstrates that libraries can really just slap #[derive(TS)] on their types. Maybe, in the future, we won't have to add support for every small crate, but they add support for us :D

[escritorio-gustavo]

I guess this demonstrates that libraries can really just slap #[derive(TS)] on their types. Maybe, in the future, we won't have to add support for every small crate, but they add support for us :D

That will be awesome to see!