Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lintkit.com/llms.txt

Use this file to discover all available pages before exploring further.

At a glance

If LintKit’s component replacement isn’t working as expected, your library probably has one or more of these issues:
  • Generic property names like Property 1 that were never renamed
  • Components named by color or appearance instead of purpose
  • Inconsistent size or state labels across families
  • Type or Variant meaning different things in different components
  • Internal helpers published alongside real components
  • Duplicate semantic paths
  • Version suffixes like _final or _v2 baked into published names

What good naming looks like

Name by purpose, not appearance

Instead of thisUse this
Blue ButtonButton/Primary
Green AlertAlert/Success
Gray TagBadge/Neutral

Use forward slashes for meaningful paths

  • Good: Actions/Button/Primary/MD/Default
  • Bad: button primary medium final

Use consistent variant property names

Use the same axes across your library:
PropertyPurposeExample values
StyleVisual hierarchyPrimary, Secondary, Ghost
SizeComponent scaleSM, MD, LG
StateInteraction statusDefault, Hover, Disabled
ModifierOptional configurationFull width, With label

Use affirmative booleans for component properties

  • Good: Show icon, Is loading, Has label
  • Also good: showIcon, isLoading, hasLabel
  • Bad: Icon=True, Label?, Hide Icon

Hide internal helpers

  • Good: .Button Base, _Input Shell
  • Bad: Publishing every internal atom and fragment

Pick a casing convention and stick to it

  • Title Case is most natural for designers in Figma
  • camelCase works for developer-aligned teams
  • The problem is mixing both in the same library

Rename these before publishing

These are Figma defaults or implementation leftovers that should never appear in a published library:
  • Property 1, Property 2 — rename to Style, Size, State, etc.
  • Unrenamed Variant or Type — rename to describe what the axis actually controls
  • Frame 104, Component 7 — replace with semantic names
  • Button_final_v2 — archive the old version, keep one canonical component
  • Blue Button, Green Alert — use role names like Primary and Success
  • Slot A, Area 1 — use role names like Header, Content, Footer

Comparison examples

ComponentAcceptableUnacceptable
ButtonActions/Button/Primary/MD/DefaultBlue Button/final/Property 1=Primary
InputData Entry/Input/Text/MD/DefaultInput Field/Component 7/Property 2=Medium
CheckboxData Entry/Checkbox/Checked/EnabledBox/On/Property 2
AlertFeedback/Alert/Critical/With IconNotice/Red/Icon=True
ModalOverlays/Modal/Dialog/MD/DefaultPopup/Overlay/Frame 102
BadgeFeedback/Badge/Success/SMTag/Green/12px
SwitchData Entry/Switch/On/EnabledToggle/Variant=On/Frame 22

Quick fixes (in priority order)

  1. Rename generic properties firstProperty 1Style, Property 2Size, etc. This is the highest-impact change.
  2. Pick one size systemXS / SM / MD / LG / XL across every family
  3. Pick one state systemDefault / Hover / Focused / Disabled / Error across every family
  4. Remove version suffixes — archive old versions, keep one canonical component
  5. Hide internal helpers — prefix with _ or ., or use “Hide when publishing”
  6. Name slots by roleHeader, Content, Footer instead of Slot A, Area 1
  7. Settle on a casing convention — Title Case or camelCase, not both in the same library

  • Every public component should have a stable, semantic path
  • Variant property names should be descriptive and consistent across families
  • Boolean component properties should be affirmative (Show icon, not Hide icon)
  • Internal helpers should not appear in the assets panel or Replace Component
  • Duplicate semantic paths should be resolved — one canonical version per component
  • Name by role, not by color, when the name represents a semantic purpose
Simple rule to remember: Name components the way a designer chooses them, not the way Figma generated them.

See also

  • Layer Naming rule — how LintKit detects default names and convention violations
  • Batch Rename — LintKit’s built-in batch rename with pattern tokens
  • Smart Replace — how LintKit uses library data for color-science matching
  • Library Mode — running LintKit inside a library file for library-specific rules