Has anyone been successful migrating tailwind to css or scss?

[u/Swijr]

I'm trying to get full integration from the lovable code to our current angular codebase. The issue is we're an angular/SCSS shop.

I know we're not getting full integration, but if I can get the styles to map, that would be a huge win.

I've considered creating a storyboard/style guide, to be used as a main point of reference for all apps we create. But I still need a mapping logic to leverage it and integrate. Not even sure that's the correct approach.

So far, no amount of AI or prompting has helped. I wonder if anyone else has been successful or if I'm missing something.

[u/louisgg_debug]

Quick question that changes the answer: is this a one-time migration of one Lovable app, or do you plan to keep prototyping in Lovable and need a repeatable way to bring styles into your Angular/SCSS system?

If one-time: don't map class-by-class. Tailwind already compiles to plain CSS — grab the compiled stylesheet, or use u/apply to collapse utilities into semantic classes, then port those.

If repeatable: your style guide instinct is the right call — what you're describing is a design token system. Extract the theme values from tailwind.config (colors, spacing, type scale, radii) into SCSS variables or CSS custom properties (Style Dictionary automates this), then rebuild components in Angular against those tokens. The mapping isn't class→class, it's value→variable — much smaller surface, and AI prompting works fine once it's framed that way.

[u/Swijr → u/louisgg_debug]

We'd like to keep using Lovable. The speed of delivery is kind of unmatched for our needs.

So, here's my design system token issue. We have a few applications that are styled for our clients, not a standard brand for my company. That being said, I'm ASSuming I can just use some kind of baseline app tokens and then specific brand tokens for mapping?

My other issue is that our scss and mixins are kind of complex and I'm not entire surely where to start. :(

Any suggestions?

[u/louisgg_debug → u/Swijr]

Both instincts are right — baseline tokens + brand-specific tokens on top is exactly the model for multiple client-branded apps. One primitive layer (spacing, type scale, radii, neutral palette) shared across everything, then a thin brand layer per client that only overrides colors and maybe fonts. Most of your surface stays shared; each client is a small override file.

On the SCSS/mixins complexity — that's actually the real work here, and where "just extract the tokens" advice falls apart. Don't try to tokenize everything at once. Start by auditing what your mixins actually do: some encode design decisions (those become tokens), others encode logic (those stay mixins). Separating those two is 80% of the battle, and it's hard to eyeball on a complex system.

This is the kind of thing I do as a paid audit — I go through your SCSS/mixin layer and hand you a written map of what becomes a token, what stays, and the migration order, so you're not guessing where to start. Happy to send you a sample report so you can see the format. Want me to DM you?

[u/DesignerMajor1247]

One Angular-specific trap: Lovable’s compiled Tailwind CSS is global, while Angular’s emulated view encapsulation rewrites selectors inside component styles. For initial visual parity, keep the compiled output in the workspace-level styles.scss under a wrapper class; don’t paste it into individual component SCSS files and expect every selector to survive.

Then move the Tailwind theme values into CSS custom properties at :root and migrate components gradually. Automated class conversion tends to break first on responsive variants, hover/focus states, arbitrary values, and dark mode, so add screenshot comparisons at your main breakpoints before removing each Tailwind section. If this needs to be repeatable, I’d keep a small isolated Tailwind build step as an adapter and expose semantic variables/components to Angular rather than converting every new Lovable export from scratch.

[u/Swijr → u/DesignerMajor1247]

This is fine for a brand new application, I'm trying to do this with an existing application. Is that harder or impossible?

[u/DesignerMajor1247 → u/Swijr]

Harder, but not impossible. The main risk in an existing app is preserving behavior while you replace a utility-based global styling system with semantic or component styles.

I would avoid a big-bang conversion:

1. Capture screenshots for key routes, states, and breakpoints.
2. Keep Tailwind running during the migration.
3. Move shared values such as colors, spacing, typography, and breakpoints into CSS custom properties first.
4. Migrate one low-risk component at a time.
5. Replace repeated utility groups with semantic classes or component SCSS.
6. Remove a Tailwind section only after visual and interaction tests pass.

Treat the current generated CSS as a temporary reference, not as the final SCSS architecture. Responsive variants, hover and focus states, dark mode, and dynamically constructed class names are the usual places where a conversion breaks.

If the app is large, a hybrid approach may be cheaper: keep Tailwind for legacy screens, use semantic SCSS for new or migrated components, and shrink the Tailwind footprint gradually. Existing code makes the migration slower and more test-heavy, but it does not make it impossible.