I have a project with the following structure:
├── Cargo.lock ├── Cargo.toml ├── build.rs └── src ├── lib.rs └── types.rs
When I build the project, the
build.rs generates a static file which will be used by the
lib.rs using include_bytes and lazy_static.
In reality I compile the project with wasm-pack to build a WASM module out of it that I can later load with a browser.
types.rs is shared between
lib.rs as it contains some common type information that is needed for compile-time and runtime.
The project is called tinysearch and the code is already on Github. It’s a tiny (~130K) search engine for static websites.
The idea is that people generate a search index for their blog at “compile time” and include the final WASM on their site.
For now, I wrapped all of this up into a
make build command but I’d like to have a stand-alone commandline utility that does the code generation.
The way I imagine it to work is
cargo install tinysearch tinysearch index.json # This will generate the WASM module
Now the question is, how I should structure my code to make both maintainable and idiomatic.
I considered the following options:
- Create a cargo workspace which consists of three crates: the binary (what is now in
build.rs), the library (
lib.rs), and a 'common" package (which contains the
- Create completely separate crates for
commonand publish all of them on crates.io. When running the
tinysearchbinary, it would download the
commoncrate, move into the
libcrate and run
I didn’t use workspaces yet, but it looks like it’s only helping me with keeping the dependencies in sync. I’d still have to publish all crates separately. So I’m not sure if it’s a possible solution.
Option 2 sounds ugly, because it feels like sidestepping cargo and shoehorning that build process in somehow.
I wonder if there’s a better solution which I’m somehow missing at the moment.
Maybe there is one where I don’t have to publish the internal dependencies on crates.io and make it somehow part of the main tinysearch