Rocket Contrib: Historical Evolution & Migration Lessons

Why Split Features Into a Separate Crate

Keeping the core framework's dependencies minimal lets projects opt into only the specific extensions they actually need, rather than pulling in everything (JSON, database pooling, templating) by default.

Features Moving Into Core Over Time

Some Rocket Contrib functionality was later folded more directly into Rocket's core crate in subsequent versions -- explaining why documentation or code from different points in Rocket's history might reference rocket_contrib for something now found directly in the main rocket crate.

Updating an Old Tutorial's Code

Following an older tutorial referencing rocket_contrib::json::Json for functionality that has since moved into core rocket means updating the import path and Cargo.toml dependency to match the current organization.

Confirming Current Organization Before Writing Code

Since crate organization has changed across Rocket's versions, checking the current official documentation or changelog for the specific version a project targets is the reliable way to confirm exactly where a given feature currently lives.

The Broader Lesson

A framework's architecture and crate/module organization aren't necessarily fixed forever -- Rocket Contrib's history illustrates a pattern seen across many frameworks, making it worth staying aware of a framework's current structure rather than assuming an older reference still applies.