langfingaz/anki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
de8f62f831
anki/rslib/proto/build.rs

24 lines
554 B
Rust
Raw Normal View History

Move protobuf generation into a separate crate; write .py interface in Rust A couple of motivations for this: - genbackend.py was somewhat messy, and difficult to change with the lack of types. The mobile clients used it as a base for their generation, so improving it will make life easier for them too, once they're ported. - It will make it easier to write a .ts generator in the future - We currently implement a bunch of helper methods on protobuf types which don't allow us to compile the protobuf types until we compile the Anki crate. If we change this in the future, we will be able to do more of the compilation up-front. We no longer need to record the services in the proto file, as we can extract the service order from the compiled protos. Support for map types has also been added.
2023-06-11 14:17:41 +02:00
// Copyright: Ankitects Pty Ltd and contributors
// License: GNU AGPL, version 3 or later; http://www.gnu.org/licenses/agpl.html
pub mod python;
pub mod rust;
Migrate to protobuf-es (#2547) * Fix .no-reduce-motion missing from graphs spinner, and not being honored * Begin migration from protobuf.js -> protobuf-es Motivation: - Protobuf-es has a nicer API: messages are represented as classes, and fields which should exist are not marked as nullable. - As it uses modules, only the proto messages we actually use get included in our bundle output. Protobuf.js put everything in a namespace, which prevented tree-shaking, and made it awkward to access inner messages. - ./run after touching a proto file drops from about 8s to 6s on my machine. The tradeoff is slower decoding/encoding (#2043), but that was mainly a concern for the graphs page, and was unblocked by https://github.com/ankitects/anki/commit/37151213cd9d431f449ba4b3bc4c0329a1d9af78 Approach/notes: - We generate the new protobuf-es interface in addition to existing protobuf.js interface, so we can migrate a module at a time, starting with the graphs module. - rslib:proto now generates RPC methods for TS in addition to the Python interface. The input-arg-unrolling behaviour of the Python generation is not required here, as we declare the input arg as a PlainMessage<T>, which marks it as requiring all fields to be provided. - i64 is represented as bigint in protobuf-es. We were using a patch to protobuf.js to get it to output Javascript numbers instead of long.js types, but now that our supported browser versions support bigint, it's probably worth biting the bullet and migrating to bigint use. Our IDs fit comfortably within MAX_SAFE_INTEGER, but that may not hold for future fields we add. - Oneofs are handled differently in protobuf-es, and are going to need some refactoring. Other notable changes: - Added a --mkdir arg to our build runner, so we can create a dir easily during the build on Windows. - Simplified the preference handling code, by wrapping the preferences in an outer store, instead of a separate store for each individual preference. This means a change to one preference will trigger a redraw of all components that depend on the preference store, but the redrawing is cheap after moving the data processing to Rust, and it makes the code easier to follow. - Drop async(Reactive).ts in favour of more explicit handling with await blocks/updating. - Renamed add_inputs_to_group() -> add_dependency(), and fixed it not adding dependencies to parent groups. Renamed add() -> add_action() for clarity. * Remove a couple of unused proto imports * Migrate card info * Migrate congrats, image occlusion, and tag editor + Fix imports for multi-word proto files. * Migrate change-notetype * Migrate deck options * Bump target to es2020; simplify ts lib list Have used caniuse.com to confirm Chromium 77, iOS 14.5 and the Chrome on Android support the full es2017-es2020 features. * Migrate import-csv * Migrate i18n and fix missing output types in .js * Migrate custom scheduling, and remove protobuf.js To mostly maintain our old API contract, we make use of protobuf-es's ability to convert to JSON, which follows the same format as protobuf.js did. It doesn't cover all case: users who were previously changing the variant of a type will need to update their code, as assigning to a new variant no longer automatically removes the old one, which will cause an error when we try to convert back from JSON. But I suspect the large majority of users are adjusting the current variant rather than creating a new one, and this saves us having to write proxy wrappers, so it seems like a reasonable compromise. One other change I made at the same time was to rename value->kind for the oneofs in our custom study protos, as 'value' was easily confused with the 'case/value' output that protobuf-es has. With protobuf.js codegen removed, touching a proto file and invoking ./run drops from about 8s to 6s. This closes #2043. * Allow tree-shaking on protobuf types * Display backend error messages in our ts alert() * Make sourcemap generation opt-in for ts-run Considerably slows down build, and not used most of the time.
2023-06-14 14:47:37 +02:00
pub mod ts;
pub mod utils;
Move protobuf generation into a separate crate; write .py interface in Rust A couple of motivations for this: - genbackend.py was somewhat messy, and difficult to change with the lack of types. The mobile clients used it as a base for their generation, so improving it will make life easier for them too, once they're ported. - It will make it easier to write a .ts generator in the future - We currently implement a bunch of helper methods on protobuf types which don't allow us to compile the protobuf types until we compile the Anki crate. If we change this in the future, we will be able to do more of the compilation up-front. We no longer need to record the services in the proto file, as we can extract the service order from the compiled protos. Support for map types has also been added.
2023-06-11 14:17:41 +02:00
use std::env;
use std::path::PathBuf;
use anyhow::Context;
use anyhow::Result;
fn main() -> Result<()> {
let descriptors_path = PathBuf::from(env::var("DESCRIPTORS_BIN").context("DESCRIPTORS_BIN")?);
let pool = rust::write_backend_proto_rs(&descriptors_path)?;
python::write_python_interface(&pool)?;
Migrate to protobuf-es (#2547) * Fix .no-reduce-motion missing from graphs spinner, and not being honored * Begin migration from protobuf.js -> protobuf-es Motivation: - Protobuf-es has a nicer API: messages are represented as classes, and fields which should exist are not marked as nullable. - As it uses modules, only the proto messages we actually use get included in our bundle output. Protobuf.js put everything in a namespace, which prevented tree-shaking, and made it awkward to access inner messages. - ./run after touching a proto file drops from about 8s to 6s on my machine. The tradeoff is slower decoding/encoding (#2043), but that was mainly a concern for the graphs page, and was unblocked by https://github.com/ankitects/anki/commit/37151213cd9d431f449ba4b3bc4c0329a1d9af78 Approach/notes: - We generate the new protobuf-es interface in addition to existing protobuf.js interface, so we can migrate a module at a time, starting with the graphs module. - rslib:proto now generates RPC methods for TS in addition to the Python interface. The input-arg-unrolling behaviour of the Python generation is not required here, as we declare the input arg as a PlainMessage<T>, which marks it as requiring all fields to be provided. - i64 is represented as bigint in protobuf-es. We were using a patch to protobuf.js to get it to output Javascript numbers instead of long.js types, but now that our supported browser versions support bigint, it's probably worth biting the bullet and migrating to bigint use. Our IDs fit comfortably within MAX_SAFE_INTEGER, but that may not hold for future fields we add. - Oneofs are handled differently in protobuf-es, and are going to need some refactoring. Other notable changes: - Added a --mkdir arg to our build runner, so we can create a dir easily during the build on Windows. - Simplified the preference handling code, by wrapping the preferences in an outer store, instead of a separate store for each individual preference. This means a change to one preference will trigger a redraw of all components that depend on the preference store, but the redrawing is cheap after moving the data processing to Rust, and it makes the code easier to follow. - Drop async(Reactive).ts in favour of more explicit handling with await blocks/updating. - Renamed add_inputs_to_group() -> add_dependency(), and fixed it not adding dependencies to parent groups. Renamed add() -> add_action() for clarity. * Remove a couple of unused proto imports * Migrate card info * Migrate congrats, image occlusion, and tag editor + Fix imports for multi-word proto files. * Migrate change-notetype * Migrate deck options * Bump target to es2020; simplify ts lib list Have used caniuse.com to confirm Chromium 77, iOS 14.5 and the Chrome on Android support the full es2017-es2020 features. * Migrate import-csv * Migrate i18n and fix missing output types in .js * Migrate custom scheduling, and remove protobuf.js To mostly maintain our old API contract, we make use of protobuf-es's ability to convert to JSON, which follows the same format as protobuf.js did. It doesn't cover all case: users who were previously changing the variant of a type will need to update their code, as assigning to a new variant no longer automatically removes the old one, which will cause an error when we try to convert back from JSON. But I suspect the large majority of users are adjusting the current variant rather than creating a new one, and this saves us having to write proxy wrappers, so it seems like a reasonable compromise. One other change I made at the same time was to rename value->kind for the oneofs in our custom study protos, as 'value' was easily confused with the 'case/value' output that protobuf-es has. With protobuf.js codegen removed, touching a proto file and invoking ./run drops from about 8s to 6s. This closes #2043. * Allow tree-shaking on protobuf types * Display backend error messages in our ts alert() * Make sourcemap generation opt-in for ts-run Considerably slows down build, and not used most of the time.
2023-06-14 14:47:37 +02:00
ts::write_ts_interface(&pool)?;
Move protobuf generation into a separate crate; write .py interface in Rust A couple of motivations for this: - genbackend.py was somewhat messy, and difficult to change with the lack of types. The mobile clients used it as a base for their generation, so improving it will make life easier for them too, once they're ported. - It will make it easier to write a .ts generator in the future - We currently implement a bunch of helper methods on protobuf types which don't allow us to compile the protobuf types until we compile the Anki crate. If we change this in the future, we will be able to do more of the compilation up-front. We no longer need to record the services in the proto file, as we can extract the service order from the compiled protos. Support for map types has also been added.
2023-06-11 14:17:41 +02:00
Ok(())
}
Reference in New Issue Copy Permalink