design-systems-slds2-migrate

Goal

Systematically migrate Lightning Web Components from SLDS 1 to SLDS 2 using the SLDS linter and structured guidance for fixing violations across all styling hook categories.

SLDS 2 Styling Hook Categories

Color hooks require the most judgment (context-dependent selection). Non-color hooks are mostly numbered scales with straightforward mappings.

Prerequisites

• Node.js 14.x or higher installed
• Access to component CSS and markup files (.html for LWC, .cmp for Aura)
• Terminal/command line access to run linter
• Git repository for backup (recommended)

Workflow

1. **REQUIRED — ALWAYS run first:** npx @salesforce-ux/slds-linter@latest lint --fix . — NEVER skip this step. This handles simple violations automatically.
2. Review linter output -> Identify remaining manual fixes needed
3. Fix by violation type -> Use per-rule reference guides
4. Choose the right hook -> Context-first, inspect HTML before deciding
5. Validate -> Re-run linter and confirm zero errors

Step 1: Run SLDS Linter

MANDATORY: This step is NOT optional.

npx @salesforce-ux/slds-linter@latest lint --fix .

The linter analyzes all CSS and markup files (.html for LWC, .cmp for Aura), auto-fixes simple violations, and reports remaining issues requiring manual intervention.

Step 2: Analyze Linter Output

The linter reports violations in this format:

Four violation types, each with its own fix approach (see Step 3).

Important: The linter flags all hardcoded values. Fix color, spacing, sizing, typography, border, and shadow values — but skip layout values (100%, auto, 0, inherit, none). See rule-no-hardcoded-values.md for the full fix-vs-skip triage table.

Step 3: Fix Violations by Type

Each rule has a dedicated reference guide with full examples and decision logic:

Always include fallback values — var(--slds-g-hook, originalValue) where originalValue is the exact original from the source CSS.

Class Override Quick Reference

Class overrides require changes to both CSS and markup (.html or .cmp). This is the most commonly missed step:

1. CSS: Rename .slds-* selector → {componentName}-{sldsElementPart} (camelCase)
2. Markup: Add the new class alongside the SLDS class — never remove the SLDS class

See rule-no-slds-class-overrides.md for descendant selectors, multi-class selectors, and naming conventions.

Step 4: Choose the Right Hook

Color hooks require context-based selection. REQUIRED: When any violation involves a color property (color, background-color, background, fill, border-color), you MUST read color-hooks-decision-guide.md BEFORE choosing a hook. The linter lists possible hooks in no particular order — do NOT pick the first suggestion. The guide contains property-based rules that determine the correct hook.

Non-color hooks are simpler — match the CSS value to the numbered scale. See non-color-hooks-decision-guide.md for value-to-hook lookup tables covering spacing, sizing, typography, borders, radius, and shadows.

Step 5: Validate and Verify

Linter feedback loop — repeat until zero errors:

Validation

• No .slds-* classes in CSS selectors
• No var(--lwc-*) tokens without SLDS 2 replacements
• All hooks include fallback values
• Background/foreground color hooks from same family
• Original SLDS classes preserved in HTML
• Spacing uses numbered hooks (not named like spacing-medium)
• Typography uses numbered hooks (not named like font-weight-bold)
• Component renders correctly in light/dark mode and density settings

See migration-checklist.md for the full validation checklist.

Output

Return the fully migrated CSS (and updated HTML markup where class overrides were fixed) with zero SLDS linter violations. All styling hooks must include fallback values preserving the original CSS values.

Advanced Patterns

Color-Mix for Transparency

When a hardcoded value uses rgba() or transparency, use color-mix() with the SLDS hook to preserve opacity:

Formula: To achieve X% opacity, use (100 - X)% transparent in color-mix.

• 70% opacity → transparent 30%
• 50% opacity → transparent 50%

Use opaque rgb() as fallback (not rgba()) — color-mix handles the transparency.

calc() Expressions with Tokens

When migrating t('calc(...)') or calc() with deprecated tokens:

For calc() with --lwc-* tokens being replaced:

Tip: Often the calc() is unnecessary and can be simplified. Check if the result matches an existing hook value.

Key Constraints

• Never invent hook names — only use hooks documented in the SLDS design system
• Always include fallback values — the fallback must be the exact original value from the source CSS
• Never change hardcoded numerical values — values like 100%, 50%, 200px, 1.5, auto, 0, inherit, none, flex: 1 are structural/layout values. Do not replace them with hooks and do not remove them — they are not styling hook candidates
• No exact match? Leave as-is — if a hardcoded value doesn't closely correspond to any hook's rendered value, leave it unchanged rather than force-fitting
• Match hook number to original value intensity — don't default to -1. Pick the variant closest to the original. See color-hooks-decision-guide.md
• Only numbered scales — named hooks like spacing-medium, font-weight-bold, radius-large do NOT exist

Troubleshooting

References

• Color Hooks Decision Guide — All 5 color hook families, decision trees, background-foreground pairing, palette accessibility
• Non-Color Hooks Decision Guide — Spacing, sizing, typography, borders, radius, and shadow hooks with lookup tables
• Rule: No Hardcoded Values — Linter behavior, fix-vs-skip triage, replacement pattern, utility class workflow
• Rule: LWC Token to SLDS Hook — Deprecated --lwc-* token replacement patterns
• Rule: No Deprecated Tokens SLDS1 — Legacy t()/token() Aura syntax replacement patterns
• Rule: No SLDS Class Overrides — Class renaming and HTML updates
• Migration Examples — Before/after examples by scenario and complexity
• Common Patterns — Classes never to override, deprecated SLDS 2 classes, palette fallbacks, tokens with no SLDS 2 equivalent
• Migration Checklist — Full validation checklist