ts-rs and types from external crates

[escritorio-gustavo]

We are talking about how to handle types from external crates (from crates.io or other sources) in two PRs (#211 and #218), so I thought this would be easier to follow

[NyxCode]

Good idea, we should probably make more use of the discussions feature!

So yeah, as I said, I can definetely see cases where it'd be nice for libraries to implement/derive TS, maybe without #[ts(export)]ing.
Same goes for git or path dependencies for those who split their project into multiple crates, but aren't using a workspace.

[escritorio-gustavo]

I currently have a working solution for workspaces, but I'm waiting on #211 (comment) to commit it

[NyxCode]

That's good to hear. Still, I think it might make sense to first figure out in which direction we want to go with this issue here, since im not sure how the two will interact.

[escritorio-gustavo]

The reason I think it's weird to have external libs implementing TS is that it assumes the consumers need it, which is a big assumption because:

• The consumer must be using TypeScript in their project
• The consumer must need to translate between Rust and TS types
• The consumer wants to do this through ts-rs

All of these assumptions are a bit of a stretch for an external crate

If all of these are wrong, the library must then assume the consumer doesn't mind an extra dependency on ts-rs

Of course, all of these problems can be mitigated by hiding ts-rs behind a feature flag

[escritorio-gustavo]

Something we could try is to force external crate types to be #[ts(inline)]d, this way we avoid the #[ts(export)] problem

[escritorio-gustavo]

I think I see your point on how it could be useful though, the same way a bunch of crates have a serde flag

[escritorio-gustavo]

@NyxCode can #195 somehow help with this?

[escritorio-gustavo]

((((), (PhantomData<i32>,)), (PhantomData<String>,)), (PhantomData<u32>,))

So this is almost like a linked list of TypeList?

[NyxCode]

yes!

[escritorio-gustavo]

I've got something similar working already, but I'm running into some Sized restrictions right now, which I'm not sure yet how to overcome.

I suspect you have a more complex situation than the playground you linked, still, in that playground I just spammed ?Sized until the errors went away
Playgrround

[NyxCode]

I suspect you have a more complex situation than the playground you linked, still, in that playground I just spammed ?Sized until the errors went away

That was the solution, btw., even though I dont completely understand why ^^

[escritorio-gustavo]

I think it's because we never get an actual value of type T, so it doesn't matter that we don't know its size

[NyxCode]

The "naive" approach of just exporting all dependencies with the type is the following:
Let's say we've got A and B, which contain an external type of a library:

#[ts(export)]
struct A {
  y: crate_y::Y	
}

#[ts(export)]
struct B {
  y: crate_y::Y	
}

For this, we'd expect this output:

bindings/
  A.ts
  B.ts
  Y.ts

Y.ts gets automatically exported as well, since the #[ts(export)]ed types depend on it.

However, the generated test for B doesn't know about the generated test for A, so both tests would try to write Y.ts.
Here, we'd need some kind of locking (either a Mutex somewhere, or locking using the filesystem) to prevent file corruption.

[escritorio-gustavo]

Maybe with the env variable proposed in #195 we could override this behavior?

[escritorio-gustavo]

Maybe with the env variable proposed in #195 we could override this behavior?

This works, but requires the following

1. Create the file: <project-root>/.cargo/config.toml
2. Add the following to the file:

[env]
TS_RS_EXPORT_DIR = { value = "<RELATIVE_PATH_FROM_PROJECT_ROOT_TO_BINDINGS_DIR>", relative = true }

3. Run cargo test -p <dependency>
4. Run cargo test

[escritorio-gustavo]

Also note that step 3 only needs to be done after dependency updates

[escritorio-gustavo]

Also, as a bonus, library authors can enforce the setting of this variable with this:

#[test]
fn env_set() {
    assert_ne!(env!("TS_RS_EXPORT_DIR"), "");
}

cargo test -p <dependency> will panic if the variable isn't set

[escritorio-gustavo]

Check out #220 to see how it works

[NyxCode]

Possible Solution Nr.3

We re-introduce something like export!, and make exporting much more explicit (and centralized in one place!).

Users would have to explicitly name everything they want to export - including types their types contains.

export!(
  MyTypeA, MyTypeB<()> => "my_types.ts",
  SomeLibraryType => "lib.ts"
);

I got rid of that quite a while back and replaced it with #[ts(export)], since I didn't like that you'd have to name every type you wanted to export. For example, every exported type would need to be public so that you can access it in your main.rs.

The big advantage of this here is that you could export multiple types in one file. This isn't easily possible with the current "one test per type" approach (though it might be, with file locking, idk)

[NyxCode]

In the workspace scenario, only the top-level crate(s) should then call export!, and include their dependencies in that.

[escritorio-gustavo]

I think i like the CLI better. As you mentioned, this forces the user to make everything pub and they need to know that passing () to the generic param is the proper way to do it

[NyxCode]

@escritorio-gustavo Now that we've explored two possible solutions already, what do you think?

Personally, I think I prefer the TypeList based one. It doesn't require a CLI right away (thogh I really want one), and from the perspective of a user everything just works like before.
My judgement might be clouded by the effort i put into that solution though, so I'd love to hear your opinion.

[escritorio-gustavo]

I like the TypeList a lot as well, especially since it ensures only types used by the consumer will get exported

[escritorio-gustavo]

It's definetly gonna solve #111 and #177 ata the same time, which is great!
It doesn't seem to clash with #195 at all, so that can be merged afterwards to allow setting a different default directory.
I don't think it solves #214, so #217 may still be needed

[NyxCode]

It's definetly gonna solve #111 and #177 ata the same time, which is great!

🥳

It doesn't seem to clash with #195 at all, so that can be merged afterwards to allow setting a different default directory.

Agreed, that's completely orthogonal

I don't think it solves #214, so #217 may still be needed

Agreed! That might have been solved if we went down the export! { .. } route (maybe).