When Your Figma Make Code Breaks in VS Code: Start by Checking the globals.css & index.css Conflict
Figma Make generates all styles inside globals.css, but during the download process, a default index.css file is also created by Vite. When you organize files in VS Code or let AI tools like Cursor or Copilot refactor the code, index.css often becomes the file that gets modified first. This splits the styling logic into two separate sources. Once you sync the code with Figma again, the mismatch between globals.css and index.css causes the UI to suddenly break. This post explains why it happens and how to build a structure that remains stable even through continuous Figma–code updates.
When exporting designs with Figma Make and working with React/Vite in VS Code, one of the most common issues is that the UI suddenly “breaks.” Buttons lose styling, spacing collapses, and the layout looks like raw HTML.
Surprisingly, this isn’t a JavaScript problem. In most cases, the root cause is simple: your project ends up with two style sources—globals.css and index.css—and they collide.
Let’s break down how this happens and how to fix it safely.
1. Figma Make always uses a single style source: globals.css
Every time you export code from Figma Make, you’ll find:
src/styles/globals.css- An import in
main.tsx:import "./styles/globals.css";
Figma regenerates this file every time code is updated. So globals.css is essentially Figma’s territory.
The problem starts when Vite steps in.
2. Vite automatically generates index.css when exporting code
During code download, you might see:
src/index.css- And sometimes
main.tsxincludes:import "./index.css"; import "./styles/globals.css";
Now the UI is driven by two style files. This alone is enough to cause subtle or severe layout issues.
3. VS Code & AI tools tend to modify index.css first
Tools like Cursor or Copilot treat index.css as the “entry point” because:
- its file name is standard
- most projects use it as the main stylesheet
- AI models are trained on common patterns where index.css is the default
As a result:
- Figma styles → globals.css
- Your custom/AI changes → index.css
Two competing sources.
When you sync with Figma again, globals.css gets regenerated, index.css stays the same, and everything becomes desynchronized. This is the moment the screen breaks.
4. A stable structure for ongoing updates: use index.css as the hub
Merging everything into globals.css seems like a quick fix, but it fails the moment Figma regenerates the file. For continuous updates, the safest structure is:
globals.css = Figma-owned fileindex.css = your main hubmain.tsx = import index.css only
main.tsx
import "./index.css";
index.css
/* Bring in Figma-generated styles */
@import "./styles/globals.css";
/* Below is your override/custom styling */
body {
font-family: system-ui, sans-serif;
}
.button-primary {
border-radius: 100px;
}
This approach gives you:
- Safe Figma → Code regeneration
- A single entry point for all styling
- A clean environment where AI tools modify only index.css
- No more CSS path conflicts
It’s the most reliable setup when your workflow constantly moves between Figma and VS Code.
5. A helpful mindset for planners & PMs
Most people assume a broken UI means “the code is wrong.” But in design-to-code workflows, the biggest cause is usually:
- two or more style entry points
- inconsistent imports
- regenerated vs hand-edited files colliding
Once you centralize your structure around index.css as the hub, even repeated Figma updates become safe and predictable.
6. A small teaser for the next post
At this point, you now have a structure that allows continuous syncing between Figma and VS Code without the UI breaking. But there’s still one more hidden problem that often appears in this workflow.
❓ When globals.css is imported inside index.css, what subtle issue appears every time Figma regenerates globals.css?
This will be the main topic of the next article— how to prevent the issue entirely.
Stay tuned for the follow-up post.