PrimeOne 4.0.0 - Token usage protection and scoping

[Pi0up]

Hi,

Primitives and semantics are for in-library use only, they could be hidden from the library publication to prevent errors ; the token list is already quite long, so anything that helps limit the number of options in the Figma interface is a win
Using token scoping also helps shorten the lists par radii, but the rest of it too. For example, we can use different tokens for 'flow' (padding/margins) and 'fixed' sizes. This improves the workflow and allows us to add specific modes for spacing, like an information density mode (compact vs. spacious)

Regards,
v.

[onursenture]

Hi,

We see the value in using variable scoping to improve clarity and support more effective workflows. Enhancements in this area are planned for future releases.

Thanks for the suggestions.

[Pi0up]

As I’m working with the existing components and creating new ones, I’ve noticed that many of them reference primitives directly instead of using semantic tokens. Since this is generally considered bad practice, do you plan to address this in a future release?

[onursenture]

Hello,

We don’t consider direct primitive references inherently bad practice. In large-scale systems like Prime, enforcing strict semantic-only rules can introduce additional complexity, so we intentionally allow some flexibility.

That said, we understand the reasoning behind semantic-only approaches and continue to monitor evolving industry practices. For now, we don’t plan to make any structural changes in this area.

[Pi0up]

Thanks,

Too bad that end users can't use your design architecture rules to extend or finetune it.
Preserve complexity on architecture level is offloading it to the end users since complexity is absolute as a matter of principle.

Nice (hard) work tough. Bravo.