As some of you may be aware, RunKit built in native support for displaying a number of Immutable classes (see figure 1 below), and we'd like to increase that support in the future. One thing we might run into though, is that due to the nature of RunKit, it actually requires some internal knowledge of immutable classes. The reason for this is that RunKit does a full object serialization on the backend, and its only the frontend that is recognizing the "shape" of the object, and merely providing an Immutable view of the data in question. One cool side effect of this is that you can actually select "properties viewer" in RunKit and see the normal JavaScript representation, which can be helpful if you are debugging immutable itself (see figure 2 below).

Figure 1

Figure 2

All this being said, it creates a potential headache in the future (which we may already be running into with 4.0.0?) if the internal representation changes. We can certainly take on the work ourselves of trying to identify the "4" shape vs "3" shape if it happens to be different, but I'd like to propose perhaps modifying the strategy from storing "true" in "@@__IMMUTABLE_LIST__@@", to storing the semver version:

{
    "@@__IMMUTABLE_LIST__@@": "4.0.0-rc.9"
}

I think this would actually be useful outside of RunKit as well. It is perhaps the case that most of the time two different versions of immutable objects can interact just fine, but this would provide an excellent way of either 1) doing a conversion if two incompatible versions are detected, or 2) being able to easily throw a very friendly error if incompatible versions are detected. I think this is very much in-line with the "spirit" of the class tag: to be able to identify that an object is indeed an immutable list even if it does not intanceof to your stored copy of the constructor.