Consider making space accessor proxy more permissive to allow for "special property" checks (e.g. __v_isRef, $$typeof)

[kleinfreund]

A colorjs.io Color object comes with what's called space accessors in the code for accessing, for example, the HSL color coordinates of a Color object in sRGB space by using color.hsl.h, etc.

This is very convenient and easy to use, but I found that this clashes with other libraries that try to use special properties to identify certain special structures (e.g. Vue's __v_isRef, Vitest's $$typeof) because it seems to consider virtually all properties that aren't found on the respective color space object invalid.

Example 1: Vue's __v_isRef

Vue.js seemingly tries to identify refs by checking for the special __v_isRef property (see vue/core code reference). Consider this code that creates a reactive proxy (see reactive docs) for a colorjs.io Color object and then subsequently accesses the HSL space's hue coordinate via property access.

test-1.js (run node test-1.js to reproduce):

import Color from 'colorjs.io'
import { reactive } from 'vue'

const color = reactive(new Color('#f60'))
console.log(color.hsl.h)

This code causes a colorjs.io TypeError triggered by the space accessor logic noticing an attempt to read a __v_isRef property.

TypeError: No "__v_isRef" coordinate found in HSL. Its coordinates are: h, s, l

Example 2: Vitest's $$typeof

I currently don't have example code that exhibits this example, but it's largely analogous to the previous one. I'm just collecting it here so that other people's web search results might lead here.

TypeError: No "$$typeof" coordinate found in HSL. Its coordinates are: h, s, l

Possible solutions

There doesn't seem to be an easy or obvious solution that doesn't in some way inhibit the current user experience because in the general case, the space accessor error as thrown is quite useful and desirable.

• Global opt out or accessor allow list: One could opt out of this error globally (throw_on_invalid_space_accessors: false, defaults to true) or even with an allow list of properties that are not to trigger the error (allowed_space_accessor_properties: ["__v_isRef", "$$typeof"], defaults to []). This is a pretty clean solution because it retains the current user experiences while allowing users like myself to allow list __v_isRef; however, it puts quite a burden on users who typically are not aware of such library implementation details. I only know of __v_isRef because I just ran into this issue and can make an educated guess about what it's doing due to familiarty with Vue, but that shouldn't be the assumed default case of a user.
• Likely coordinate accessor name heuristic: One could employ an extremely naive heuristic by using the observation that all current coordinate accessors are single or double character strings (see https://colorjs.io/docs/spaces). One could throw this error only if the property that's being accessed is two characters or shorter. While this would address the two problem cases I show above, it's not nice because it's intransparent to the user and needlessly puts a constraint on how future coordinate accessors may be called. It, of course, also wouldn't protect against legitimate "special property" checks that happen to use two or fewer characters (though this seems unlikely).

Notes

• I'm using colorjs.io built from the current repository state (i.e. github:color-js/color.js#2e9dd5cc2362b8b81669247a4c71980d5e945b1f)
• Related issues:
  • Color.js objects cannot be wrapped in a Proxy (and thus, cannot be used with Vue or other Proxy-based libraries) #305 though this is more about the general use of private fields with proxies