fix: prioritize config preference over stored value when not 'system'

[abolix]

This fixes an issue where explicitly configured color mode preferences (like preference: 'light') would be overridden by previously stored values from localStorage/cookies.

When a user sets preference to a specific mode (not 'system'), it should take precedence over any stored preferences from previous sessions.

Fixes: Color mode preference not respected when switching between projects

🔗 Linked issue

Fixes #318

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

[netlify]

👷 Deploy Preview for nuxt-color-mode processing.

Name	Link
🔨 Latest commit	bbfadef
🔍 Latest deploy log	https://app.netlify.com/projects/nuxt-color-mode/deploys/68b957c19f68c70007611b3a

[netlify]

✅ Deploy Preview for nuxt-color-mode canceled.

Name	Link
🔨 Latest commit	dc1002d
🔍 Latest deploy log	https://app.netlify.com/projects/nuxt-color-mode/deploys/68c1335d958d5500086fc276

[danielroe]

this doesn't seem correct to me.

options.preference here is not set by the user but by you, and therefore it should never override the user's choice.

it is the 'default' preference

color-mode/src/module.ts

Line 87 in eaff67e

* The default value of $colorMode.preference

there's a different way to force a color mode if you need to

[abolix]

Well it's not exactly the problem, can you please look at the issue #318 so I don't have to explain all over again ?

it's mainly about running 2 project in different times at the same port when one project is forced on dark and one is forced on light, it does not switch automatically and we have to clear localstorage

[danielroe]

i read it but i'm have you understood my comment?

this change breaks the functionality of this module in production by changing a 'default' to an override

[abolix]

understood but is there any other way that without breaking the functionality we can implement this ?

[danielroe]

would you spell out your desired behaviour, as clearly as possible, and addressing any edge cases or differences between how things work in production and in development?