Add minimal wasm and local-only feature support#37
Add minimal wasm and local-only feature support#37jolestar wants to merge 3 commits intoMinishLab:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds explicit Cargo feature flags and documentation for minimal wasm32-unknown-unknown builds, keeping wasm support scoped to local/in-memory model loading.
Changes:
- Introduces
local-onlyandwasmCargo features (withwasmenablingtokenizers/unstable_wasm). - Documents feature combinations and a minimal wasm check command (including the
getrandombackend cfg) in the README. - Updates
Cargo.lockdue to new wasm-related dependency resolution (e.g.,js-sys,wasm-bindgenviagetrandom).
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| README.md | Adds “Feature flags” section + wasm check command documentation. |
| Cargo.toml | Adds local-only and wasm feature definitions. |
| Cargo.lock | Reflects dependency changes pulled in for wasm-related builds. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| default = ["onig", "hf-hub"] | ||
| hf-hub = ["dep:hf-hub"] | ||
| local-only = [] |
There was a problem hiding this comment.
local-only is currently a marker feature with no code-level effect: the remote-download path is gated only by feature = "hf-hub" (see src/model.rs:380+). As a result, enabling local-only alongside hf-hub still allows remote model downloads, contradicting the README wording. Consider enforcing the restriction in code (e.g., disable/compile-error the remote branch when local-only is enabled) and adding a test that verifies remote from_pretrained fails under local-only even if hf-hub is on.
| The crate exposes a few feature combinations for different runtimes: | ||
|
|
||
| * `default`: native build with `onig` tokenization and optional Hugging Face Hub downloads | ||
| * `fancy-regex`: alternative tokenizer backend for native builds | ||
| * `local-only`: restrict loading to local paths or `from_bytes(...)` | ||
| * `wasm`: minimal WebAssembly-oriented feature set for local or in-memory loading | ||
|
|
There was a problem hiding this comment.
The feature list implies local-only and wasm are standalone “feature combinations”, but local-only doesn’t currently change behavior by itself, and wasm will generally need to be used with --no-default-features (otherwise default enables onig/hf-hub, which is not wasm-friendly). Suggest clarifying the expected invocation patterns (e.g., --no-default-features --features wasm / --no-default-features --features onig,local-only) to avoid confusing or non-working builds.
README.md
Outdated
| * `wasm`: minimal WebAssembly-oriented feature set for local or in-memory loading | ||
|
|
||
| The `wasm` feature is intended for `wasm32-unknown-unknown` builds that only load | ||
| models from local files or in-memory bytes. Remote Hugging Face downloads are not |
There was a problem hiding this comment.
For wasm32-unknown-unknown, Rust’s standard library typically doesn’t provide direct filesystem access, so “load models from local files” may be misleading for browser/JS environments. Consider tightening this wording to emphasize from_bytes(...) (or clarify that “local files” requires a host-provided filesystem such as WASI/Node bindings).
| * `wasm`: minimal WebAssembly-oriented feature set for local or in-memory loading | |
| The `wasm` feature is intended for `wasm32-unknown-unknown` builds that only load | |
| models from local files or in-memory bytes. Remote Hugging Face downloads are not | |
| * `wasm`: minimal WebAssembly-oriented feature set for in-memory loading via `from_bytes(...)` | |
| The `wasm` feature is intended for `wasm32-unknown-unknown` builds that load models | |
| from in-memory bytes (for example, data fetched over HTTP or embedded into the | |
| binary). Rust’s standard library does not provide direct filesystem access in | |
| typical browser/JS WebAssembly environments; if you want to work with “local files” | |
| you must supply a host-side filesystem (such as WASI or Node.js bindings) and pass | |
| the file contents into `from_bytes(...)`. Remote Hugging Face downloads are not |
Summary
local-onlyandwasmfeature flagswasm32-unknown-unknowncheck commandDetails
This keeps the change intentionally small:
local-onlyis an explicit feature for builds that should avoid remote model downloadswasmbuilds on top oflocal-onlyand enablestokenizers/unstable_wasmgetrandombackend flag forwasm32-unknown-unknownThis PR does not add browser or worker integration, and it does not change the default native feature set.
Validation
cargo +stable test --verbosecargo +stable test --no-default-features --features fancy-regex --verbosecargo +stable clippy --all-targets --all-features -- -D warningscargo +stable fmt --all -- --checkRUSTFLAGS='--cfg getrandom_backend="wasm_js"' cargo check --no-default-features --features wasm --target wasm32-unknown-unknownQuestion
If this direction looks good, would you also be open to a follow-up PR that adds a minimal wasm check to CI, for example:
RUSTFLAGS='--cfg getrandom_backend="wasm_js"' \ cargo check --no-default-features --features wasm --target wasm32-unknown-unknown