Best practices for naming components, layers, and variant properties so your library works well with LintKit and your whole team.
Good naming makes your library easier to browse, improves developer handoff, helps AI code generation via MCP, and gives LintKit better data for component replacement. This page covers what good naming looks like, why it matters, and how to fix common problems.
This guide is for design system teams, product designers maintaining shared libraries, design ops teams cleaning up legacy component files, and anyone using LintKit’s component replacement features.LintKit works best when your library names describe what a component is and how a designer would choose it, not how Figma happened to generate it.
LintKit can do a much better job when your library is semantic, consistent, scannable, machine-readable, and cleanly separated between public and internal assets.In practice, that means your library should have:
Stable component paths
Meaningful page and section structure
Predictable variant property names
Controlled vocabularies for values
Affirmative boolean labels
Unique semantic paths
Internal helpers hidden from publishing
LintKit will likely struggle when it sees Property 1, duplicate paths, Type used inconsistently, helper contamination, or icons and templates mixed into public component pages.
Do not create both Forms and Data Entry unless you have a strict rule for the difference. Category drift is how libraries turn into attic boxes labeled “misc.”
Has Icon, Allow Clear, Loading, Full Width, Show Label
If one button uses Type=Primary, State=Hover, Size=Large but another uses Variant=Main, Status=Over, Scale=LG, your library becomes harder for designers to scan and harder for tooling to normalize.
Type is one of the most overloaded names in component libraries. It might mean style, subtype, status, treatment, or even state.In one family Type=Primary means visual hierarchy. In another, Type=Search means input subtype. In another, Type=Success means feedback tone. Those are three different semantic jobs wearing the same name.Use more specific property names:
Boolean properties should read like a clear yes/no question. Use affirmative prefixes: is, has, show.
Bad
Better
Hide Icon
showIcon
Visible
isVisible or showContent
Label?
hasLabel
Selected
isSelected
If the property name is Hide Icon and the value is true, what does that mean? That ambiguity is error-prone. Flip to showIcon so true means “the icon is visible.”
One of the biggest reasons Replace Component gets messy is helper contamination. Internal parts, slots, atoms, fragments, and scaffolding should not appear in the assets panel.Public components are things users actually insert: Button, Input, Card, Badge, Modal, Alert.Internal helpers should stay hidden: button bases, icon glyph wrappers, row fragments, cells, scaffolds, layout shells.Hide internal-only pieces using:
. prefix (e.g. .Button Base)
_ prefix (e.g. _Input Shell)
Figma’s “Hide when publishing” behavior
Simple rule: If the component is mainly used inside another component, it probably should not appear in Replace Component.
Use this when your library is already messy and you need to improve it fast.Fix 1: Rename generic properties first. If you see Property 1, Property 2, or Variant, rename them immediately to Style, Size, State, Modifier, Tone, or Subtype.Fix 2: Standardize size naming. Pick XS/SM/MD/LG/XL or Small/Medium/Large, then update every similar family to match.Fix 3: Standardize state naming. Choose one set: Default, Hover, Focused, Pressed, Disabled, Error, Selected, Checked. Avoid mixing Rest, Base, Normal, and Default.Fix 4: Remove version suffixes. Replace _v2, _final, _new — archive the old version, keep one canonical published component.Fix 5: Hide internal helpers. Prefix internal-only components with . or _, or hide them from publishing.Fix 6: Move organization out of bloated names. If component paths are getting too long, move grouping into pages and sections.Fix 7: Add descriptions to public components. Descriptions help users understand when to use it, when not to, and what conventions it follows.
That is the kind of structure both humans and tools can reason about.
If you want Replace Component to feel smart, your library has to stop speaking in implementation leftovers and start speaking in product language. The goal is easier browsing, fewer mistakes, better design-to-code parity, and cleaner replacement results.
LintKit’s naming rule catches three categories of problems:
Default Figma names — Frame 47, Rectangle 12, Group 7, Text 3, and other auto-generated names that tell developers nothing about the layer’s purpose.
Forbidden patterns — copy suffixes (Button copy 2), temp labels (WIP Header, TODO fix this), and other placeholders that should never appear in a published file.
Convention violations — when your file has a dominant naming style (like camelCase) and some layers break it (like hero-banner in kebab-case).
This tab walks through how to fix the most common naming problems in your library.
Variant properties are the dropdowns designers see when selecting a variant. Default names like Property 1 give no context about what the property controls.
1
Select the component set in your library file
Click the component set (the purple dashed border) — not an individual variant inside it.
2
Open the Design panel
Look for the variant property names listed under the component set name. You’ll see names like Property 1, Property 2, etc.
3
Rename the property
Click the property name to edit it. Replace generic names with descriptive ones:
Slots and sub-layers are the internal parts of a component that designers can customize. Default names like Frame 12 make it impossible to know which slot does what.
1
Enter editing mode
Double-click into the component to edit its internal layers.
2
Rename layers in the layers panel
Click each layer name in the left sidebar and type a descriptive name that describes the layer’s role.
Internal components (button bases, icon wrappers, layout scaffolds) clutter the assets panel and confuse Replace Component. Three ways to hide them:
1
Option A: Prefix with . or _
Rename the component to .Button Base or _Input Shell. Figma automatically hides dot-prefixed components from library publishing.
2
Option B: Right-click → Hide when publishing
Right-click any component in a library file and select Hide when publishing. The component stays usable inside the file but won’t appear in the assets panel for consumers.
3
Option C: Move to a private page
Create a page called _Internal or .Helpers and move internal components there. Components on pages with . or _ prefixes are excluded from publishing.
Simple rule: If a component is mainly used inside another component, it probably should not appear in your library’s assets panel.
LintKit also has a built-in Batch Rename feature that works directly from naming findings. It supports pattern tokens like {n}, {parent}, and {type} for more structured renaming.
When different component families use different size labels (Small, sm, S, 16), the library feels inconsistent and tooling can’t match across families.
1
Pick one size vocabulary
The most common choice is T-shirt sizes: XS, SM, MD, LG, XL. Alternatively, use Small, Medium, Large — but pick one and stick to it.
2
Open each component set with a size property
Go through your library and find every component set that has a size variant.
3
Rename each variant value to match
Click the variant value in the Design panel and rename it:
Small → SM
Medium → MD
Large → LG
4
Repeat for every component family
Do this for buttons, inputs, badges, avatars, and every other component with a size property.
This is tedious but one-time. Once standardized, new variants follow the pattern naturally.
When you find components like Card_v2, Card Final, Card fixed, it means the library has accumulated drafts that were never cleaned up.
1
Decide which is the canonical version
Look at which version is most widely used across your files. That’s your canonical component.
2
Archive the old versions
Move old versions to a page called _Archive or _Deprecated. This keeps them accessible but out of the main library.
3
Rename the canonical version
Remove the version suffix: Card_v2 → Card. This is now the single source of truth.
4
Migrate existing instances
If instances of the old version exist in consumer files, use Figma’s Swap component feature to migrate them to the canonical version.
5
Delete or hide the archived versions
Once all instances are migrated, hide or delete the old versions so they stop appearing in the assets panel.
Before deleting old component versions, use Figma’s Go to main component on existing instances to make sure nothing is still pointing at the version you’re about to remove.
