@css blocks vs css() function: selector nesting versus interpolation during Stylus migration

Migration context

A team is incrementally migrating a legacy Sass codebase to Stylus 0.64 while maintaining zero-downtime deployments. Existing component files contain raw CSS snippets that rely on Sass variables and nested selector structures. The goal is to embed these snippets in Stylus files without rewriting selector hierarchies or losing variable references.

Conflicting mechanisms

Stylus offers two documented ways to embed literal CSS: @css { ... } blocks and the css('...') function. @css blocks preserve the current selector nesting context — rules inside them concatenate with parent selectors — but treat content as opaque text, so Stylus interpolation (#{var}) is not resolved. The css() function evaluates its string argument, allowing interpolation of Stylus variables, yet injects the result as a raw string without nesting awareness, which can break expected selector hierarchy.

Constraint

The migration must keep selector nesting intact for existing component scopes while also substituting design-token variables (colors, spacing) that are defined in Stylus. Rewriting all legacy snippets to native Stylus syntax in one pass is not feasible; the transition needs a per-file strategy that avoids runtime CSS regressions.

Which approach — @css blocks with manual variable replacement, css() calls with constructed selector strings, or a hybrid per-snippet decision — provides a predictable path for preserving both nesting and token substitution? How can the team verify selector output and interpolation results automatically during CI without rendering full pages?