Please let's avoid in-range breaking changes

[trusktr]

Describe the bug

The following demo is now broken because something in Solid changed.

Your Example Website or App

https://codepen.io/trusktr/pen/NWNaMZa

Steps to Reproduce the Bug or Issue

Click on the box. The number does not increment.

Expected behavior

As a user, I expect use of SemVer to mean that I will prevent breaking changes in my previous creations.

Screenshots or Videos

No response

Platform

• OS: any
• Browser: any

Additional context

The given example is using standard SemVer versioning, but Solid released an in-range breaking change, so the example no longer works.

There is no code bug here. It is known that Solid releases in-range breaking changes intentionally. This is considered a bad practice by many!

[yume-chan]

Isn't it because https://esm.sh/@lume/element@^0.7.0/dist/variable.js is importing /stable/solid-js@1.7.7/es2022/solid-js.mjs so there are two Solid instances?

It works after replacing

import { variable } from "https://esm.sh/@lume/element@^0.7.0/dist/variable.js";

with

import { variable } from "https://esm.sh/@lume/variable@0.8.0?deps=solid-js@^1.0.0";

[ryansolid]

@yume-chan Thank you. You are correct. I see two versions of Solid and when we get around to updating the Signals there are no observers which is pretty surefire sign of this. Looks like the templating is on 1.7.8 and the application is on 1.7.7.

[trusktr]

Hmmm, I wonder (even if it was my fault, sorry about that if it was), could Solid try to pull its internals from a global cache to attempt to still work even if there are duplicates? In some cases (f.e. Solid differs only by a minor or patch number) it might work.