Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider updating schemars_derive to use syn v2 #262

Closed
AlexTMjugador opened this issue Jan 27, 2024 · 1 comment
Closed

Consider updating schemars_derive to use syn v2 #262

AlexTMjugador opened this issue Jan 27, 2024 · 1 comment

Comments

@AlexTMjugador
Copy link

AlexTMjugador commented Jan 27, 2024

Hey, thanks for your work on this great crate!

At the moment, 80% of the Rust crates on crates.io depend on syn v2, which is not semver-compatible with syn v1, and thus not used for resolving schemars_derive's dependency on syn. Incidentally, schemars_derive is the 49th most downloaded depender on syn, and most of the remaining top dependers have already migrated to v2.

Keeping these numbers in mind, I think it's important for schemars_derive to migrate to syn v2 to play nicer with the majority of the ecosystem: because most crates now use syn v2, schemars_derive most likely causes Cargo to download and build at least two major versions of syn. This has a significant impact in build times, as shown in the following cargo build --release --timings excerpt for a project I work on. No other crate in the dependency tree of this project depends on syn v1, and that's likely to be the case for many projects.

cargo build --release --timings excerpt

In addition to the objective reason of less optimal dependency resolution, a continued dependency on syn v1 also introduces subjective concerns related to the ability of schemars to adapt to the evolving Rust language syntax: syn releases are closely associated with Rust syntax changes, and syn v1 no longer receives patches.

I have tried to update schemars_derive to use syn v2 myself, but it's an intricate refactor due to the extensive usage of the now removed syn::NestedMeta type, and in general the different APIs that should now be used for parsing nested attribute metadata. Before committing further time to this endeavor, I'd like to know your thoughts about it, and whether you already had some plan for it in mind 😄

@AlexTMjugador
Copy link
Author

This issue was solved with the merge of #281 and the subsequent release of schemars v0.8.17.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant