Publish 8.0.0

[NyxCode]

Todos

• Make sure docs are up-to-date
  • Document #[ts(as)]
  • Document #[ts(tag)] for structs
• Create GitHub release with changelog
  • Update changelog with latest PRs
• Merge Make #[ts(export_to = "...")] relative to TS_RS_EXPORT_DIR #250
• Update all dependencies

[escritorio-gustavo]

Hey @NyxCode, just merged #250, sorry I didn't yesterday, I sent the last commit and had to leave before CI finished running

[NyxCode]

Absolutely no problem, I'm in no hurry here!

[escritorio-gustavo]

Another idea I'd like to throw out there:
People sometimes complain about the whole test thing, we could remedy that by having our tests be #[ignore]d and have people run cargo test export_bindings_ -- --ignored. That's a much more annoying command to type, but TS bindings shouldn't change all that often, so people would only have to run this very ocasionally.

This would solve peoples complaints about ts-rs running when they just want to run their own tests and vice versa, running their tests when they just want to run ts-rs

We could also put this command in the ignore message, so no one needs to memorize it

[NyxCode]

Yeah, this is something I'd really want to do at some point.
I feel like this would be a good change to roll out together with a CLI tool, to completely hide this implementation detail from the user.
Introducing a change now, only to introduce a CLI in the next version feels a bit weird to me.
What do you think about the intersection of these two features?

I guess I'm also not against introducing a CLI in 8.0, but it's starting to feel like feature creep

[escritorio-gustavo]

I feel like this would be a good change to roll out together with a CLI tool, to completely hide this implementation detail from the user.

Makes sense, the user shouldn't need to know the name of our generated tests happens to start with export_bindings_

I guess I'm also not against introducing a CLI in 8.0, but it's starting to feel like feature creep

Yeah, that feels like a lot to add in a single version, there's already like 5 new attributes or something, a new env variable, new constants, associated types...

Introducing a change now, only to introduce a CLI in the next version feels a bit weird to me.
What do you think about the intersection of these two features?

I'm fine with it as well, we can keep #253 as a draft PR and merge it when the CLI lands

[NyxCode]

For an initial version, I think the CLI just needs to turn
cargo ts --out ./output --no-warnings --esm-imports into TS_RS_EXPORT_DIR=./output TS_RS_GENERATE_TESTS=1 cargo test ts_rs_export_bindings --features ts-rs/import-esm ts-rs/no-serde-warnings

[escritorio-gustavo]

Plus -- --ignored, but this needs our ignored doc tests to be no_run instead of ignore

[NyxCode]

Right, I'll need to think about this a bit more when the CLI is on the way.
I think there are a couple of other options, like only generating the tests when an environment variable is present. But again, I'll need to think about this then.

[escritorio-gustavo]

Another thing, our supported versions of heapless, ordered-float and bigdecimal, as well as our currently used version of dprint-plugin-typescript are outdated, should we use the major version bump to update them?

[NyxCode]

You're right! Added that to the todo.
Might be nice to specify a version range from what we've got now up to the newest version.

[escritorio-gustavo]

Hey @NyxCode, one other thing that might be worth looking into. What if we moved the bulk of ts_rs_macros to a new ts_rs_core crate?

In #249 you suggested creating a new crate for function support, but it'd need access to stuff like DerivedTS, which is not possible if it is defined in a proc-macro crate, due to the fact that the only pub items allowed in them are the proc-macros themselves.

We could leave only the macro entry point in ts_rs_macros and move all the rest to a core crate to make sharing stuff easier

[NyxCode]

Interesting idea. I've seen a couple macro do that, and it would allow us to re-use that logic in an other proc-macro crate.

However, in #249, I had something slightly different in mind. I'll explain the idea there in a bit more detail. However, it's just an idea, nothing I thought deeply about.

[escritorio-gustavo]

and it would allow us to re-use that logic in an other proc-macro crate.

That's the main idea. In #229 we even had a format_docs function that had to be duplicated because it was needed in both ts_rs and ts_rs_macros. Since a proc macro crate can't make a function pub and ts_rs_macros cannot depend on ts_rs, there was no way to share the function between the two crates. We did manage to eliminate this function entirely, but something like this could happen again quite easily.

A ts_rs_core crate could make anything that's needed across the other crates pub and all the other crates can depend on it.