Replace log with tracing in WASM crate

[neuronull]

🎟️ Tracking

📔 Objective

Cascading the standardization of tracing crate from clients repo into the SDK, that was started per bitwarden/clients#16321

, this change updates the WASM crate to use tracing.

📸 Screenshots

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
  team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
  issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[github-actions]

Checkmarx One – Scan Summary & Details – 6a614f7f-23b7-4aa1-ac1f-5c6f8bbefc61

Great job! No new security vulnerabilities introduced in this pull request

[codecov]

Codecov Report

❌ Patch coverage is 0% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.65%. Comparing base (00c854d) to head (585a91b).

Files with missing lines	Patch %	Lines
crates/bitwarden-wasm-internal/src/init.rs	0.00%	15 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #550      +/-   ##
==========================================
+ Coverage   79.63%   79.65%   +0.01%     
==========================================
  Files         302      302              
  Lines       32248    32251       +3     
==========================================
+ Hits        25682    25688       +6     
+ Misses       6566     6563       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[neuronull]

It looks like this wasn't being used anywhere. There is a way to dynamically reload the tracing subscriber but I didn't want to add that if it isn't being utilized.

[claude]

Claude finished @neuronull's task —— View job

---

Code Review: Replace log with tracing in WASM crate

Thanks for standardizing on tracing across the SDK! The migration from log/console_log to tracing/tracing-web is well-executed. Here's my review:

---

Summary of Changes Since Last Review

The latest commits switched from wasm-tracing to tracing-web and disabled the timer feature (which was causing crashes in web environments). The implementation now properly configures tracing for WASM with browser console output and performance tracking.

---

Critical Issues

None found. The implementation correctly addresses the web environment constraints.

---

Suggested Improvements

Finding 1: 💭 Consider documenting the removal of set_log_level function

The set_log_level function was removed without a replacement. While the review comment mentions it wasn't being used, this is a breaking API change for the WASM bindings. Per CLAUDE.md guidelines, breaking API changes should document the migration path for clients.

Suggested documentation approach

If this function is truly unused by all consuming clients (web, desktop), consider adding a note in the PR description or commit message explaining:

• That set_log_level was removed
• Why it was removed (not used, no equivalent dynamic reload in new implementation)
• That clients should only use init_sdk with the desired log level

If any client was using it, you may need to add back a dynamic reload capability using tracing-subscriber::reload.

---

Finding 2: 🎨 The performance_layer could be made optional

The performance layer adds instrumentation overhead that may not be needed in production. Consider making it configurable:

Example approach

#[wasm_bindgen]
pub struct SdkConfig {
    log_level: Option<LogLevel>,
    enable_performance_tracking: bool,
}

// Then conditionally add the layer
let mut layers = Vec::new();
if config.enable_performance_tracking {
    layers.push(performance_layer().with_details_from_fields(Pretty::default()));
}

This allows consuming applications to disable performance tracking in production builds if desired.

---

Finding 3: 💭 ANSI colors are disabled but tracing-web supports styling

The comment says "only partially supported across browsers" for ANSI, but tracing-web provides native browser console styling (the colors visible in your screenshot). The .with_ansi(false) setting is correct for WASM, but the comment could be more precise.

Suggested clarification

.with_ansi(false) // ANSI codes not needed - tracing-web uses native browser console styling

This clarifies that you're getting colors through the browser's native console API, not ANSI escape codes.

---

Finding 4: ⚠️ Codecov reports 0% coverage for new code

The 15 lines of new logging initialization code have no test coverage. While testing logging setup in WASM is challenging, consider:

• Adding a basic test that calls init_sdk without panicking
• Or documenting in the PR that manual validation was performed (you mentioned testing with desktop client)

The manual validation comment in the review thread is good, but it's not captured as part of the permanent test record.

---

Finding 5: 💭 tracing-web version could be workspace-managed

The tracing-web = { version = "0.1.3" } dependency in crates/bitwarden-wasm-internal/Cargo.toml uses a hardcoded version. Consider adding it to the workspace dependencies in the root Cargo.toml for consistency with other dependencies like tracing and tracing-subscriber.

Suggested change

Root Cargo.toml:

tracing-web = { version = "0.1.3" }

crates/bitwarden-wasm-internal/Cargo.toml:

tracing-web = { workspace = true }

This maintains version consistency across the workspace and makes future updates easier.

---

Good Practices Observed

• Timer properly disabled for web environment compatibility
• Clean removal of console_log and log dependencies
• Appropriate use of EnvFilter for environment-based configuration
• Performance layer integration for debugging capabilities

---

Action Items for Author

1. 💭 Consider documenting the set_log_level removal in PR description or commit message
2. 🎨 Optionally make performance tracking configurable
3. ⚠️ Consider adding basic test coverage or documenting manual validation approach
4. 💭 Optionally move tracing-web to workspace dependencies

---

[neuronull]

Note in the latest commit I switch to use wasm-tracing. Of the crates out there that accomplish the goal, this one is the most recently well maintained. And it provides support for enabling the colors in the console.

[github-actions]

🔍 SDK Breaking Change Detection Results

SDK Version: autofill/pm-26931/use-tracing-in-wasm-crate (726db7c)
Completed: 2025-11-19 16:48:09 UTC
Total Time: 215s

Client	Status	Details
typescript	✅ No breaking changes detected	TypeScript compilation passed with new SDK version - View Details

---

Breaking change detection completed. View SDK workflow

[neuronull]

Note in the latest commit I switch to use wasm-tracing. Of the crates out there that accomplish the goal, this one is the most recently well maintained. And it provides support for enabling the colors in the console.

reverted that, @quexten noted that if we need to add layers as we may with flight recorder, wasm-tracing doesn't allow that. and it apparently doesn't support instrument .