sync-test was removed from the workspace some time ago, which meant it
was never built or checked, so it went quite stale, particularly with
respect to logins changes.
We not keep it in the workspace but as an "excluded" item, which means
you can run it from its directory. To prevent it going stale again, CI
runs clippy on it.
Also needed a few misc tweaks to some other crates.
- creates the infra required for mdbook (as stolen from glean)
- removes unfinished, unmaintained sync-storage-handbook and synconomicon
- includes a build script for mdbook (tools/build-book.sh - modified from glean)
- adds a SUMMARY.md file - which provides the mdbook TOC
This is a substantial refactor of the fxa-client crate, intended to bring it
up to speed with our latest best-practices around developing cross-platform
Rust components, in order to ease ongoing maintenance.
THe core change here is that I've deleted the hand-written Kotlin and Swift
bindings, replacing them with autogenerated bindings thanks to UniFFI.
There is still a little bit of hand-written Kotlin, since we have a layer that
automatically manages persistence via a callback. There is still a nontrivial
amount of hand-written Swift, since we have a higher-level state machine built
atop the lower-level fxa-client functionality (such state-machine also exists
for Kotlin, but lives in the android-components repo). If UniFFI works out then
we should look into moving more of that logic into shared Rust code over time.
To support the introduction of UniFFI, I have restructured to Rust crate so
that its public interface deliberately parallels the interface offered to
Kotlin and Swift, and have moved the implementation details into a submodule
named `internal`. It's my opinionated belief that structuring the crate this
way will help us focus on producing a nice consumer API, which is not always
the same thing as producing a nice Rust crate.
On top of that, I've also revamped the documentation in the crate, leaning
in to the use of `cargo doc` as the source of truth for both developer-
and consumer-facing documentation. Let's consider that an experiment and
see how we like it in practice.
Unfortunately, this is a big PR, but I don't think I could have made it
too much smaller. Hopefully it will be easier to review than its size
suggests since it's mostly additions and deletions rather than complex
changes.
The most important one is that we avoid publishing a new set of aars
if no code has actually changed. I'm not thrilled about the *way* we
accomplish it, but it works for me.
Drew Willcoxon
Bastian Gruber
Bastian Gruber
Barret Rennie
Charlie
Tarik Eshaq
Mark Hammond
Sammy Khamis
Janet Dragojevic
Ryan Kelly
Jan-Erik Rediger
Mihai Tabara
Ryan Kelly
Edouard Oger
Garvan Keeley
Thom Chiovoloni
Thom
vladikoff