LAUNCHED: Remove "move style definition into this file"

Yeah definitely seems like a flaw, there is no way to disable this currently.

Yes, indeed. I believe flaw might be an understatement, to be completely honest. We’ve already experienced that our color palette has had several colors being detached, because of this. Which means that a lot of our DS components is also detached. It took my team a lot of time and investegation skills to try to figure out what happened. We were lucky that we discovered it pretty fast, but it could happen again as the number of Figma users in our organization is increasing. We would really appreciate it being removed for users who do not have edit and/or make it an option with an alert before continuing moving colors.

I ran into this almost 2 years ago (same usecase of trying to share a read-only DS) I didn’t realize it will actually remove the Style from the DS…always thought it would just duplicate the style into your local file.

Interesting find and a little scary 🤔

Yes, that was what my colleague tought as well. It is scary indeed, especially when users are supposed to be able to only “view”.

I just posted an issue encountering the same issue, although it was caused by me. This is a huge, HUGE bug that needs to be fixed ASAP. The fact that anyone could break an entire design library like this is awful!

Yes, it can easily happen to you colleagues or yourself. It is a dangerous button. I don’t know what the purpose of this button is. It doesn’t make any sense. However, spread the word as I would feel better if it was removed or that the functionality was “copy” and not “move”.

I suppose it’s there if you ever wanted to separate your components from your styles.

However, it’s completely bugged. If you do it and try to undo it with CMD+Z, the style is forever lost and glitched.

That, added with the fact that anyone can do it… 😬

I’ve had this happen early on in our DS Library creation and unless you inform your editors, especially those starting out in Figma, it is bound to happen. But as a Library author, this is a necessary feature so I am not suggesting we remove it.

I would, however, second the suggestion of adding the “Copy style definition into this file” action because that is usually what people want to do. This would also make it clear that “move” is not the same as “copy.”

Ooooooh that is what happened! I accidentally removed one of my primary colour styles this way, spent hours fixing this by adding a new colour and manually relinking everything… And now I can’t get that new style to publish anymore. That is to say, it constantly sees it as a new colour and it never ever gets actually published. I can’t access that new colour from other files either now. 😦 Please please please fix!

@anon21722796 will this ever be fixed? 😕

@anon21722796 really disappointed in the lack of action on this. You’re allowing any user of a library to remove a widely used style definition and with no easy way to identify where it went and what to do about it

This just happened to my team and it boggles our mind that an action this destructive is this accessible. Plz halp @anon21722796

This happened to me as well, and I managed to reverse the action.

What happened
I use a text style called “caption” from a separate design library file. On a working file (with over 30 pages) I accidentally clicked the “Move style definition into this file” and immediately hit CMD + Z to undo the action. As a result, the style was gone from my working file.

What fixed it (edit: almost)
On the design system file the “caption” style had two options:

1. View the style in the working file (“Go to style definition to edit”) where the style had been moved.
2. Move the style back to the design library file (“Move style definition into this file”).

Clicking the second option moved the style from the working file back to the design library. It also seemed to fix the unlinked content from the working file, and now everything seems to be as it was before.

Edit: Now when I update the style in the design library, the changes aren’t reflected in the working file anymore. Weirdly enough, the change I made (line-height bump from 12 to 14px) can be seen in the list of styles, but when unlinking the style, the “real” (wrong) line-height appears.

While trying to reproduce the problem with another working file and library, I was prompted with a dialog warning about the consequences of the action of moving a style out of the library:

I don’t know why this dialog didn’t appear on the other library. Maybe because the working file is the only one using the design library file?

Same issue here, bump.

Thank you all for your patience feedback!

We’ve improved the moving styles experience so that it’s a lot simpler using cut and paste. Learn more at our Help Center.