multiple ember-modifier addon versions breaking builds in subtle and different ways

[void-mAlex]

I've noticed an issue related to ember-modifier that I've come across a few times doing updates now. It's probably something that will happen quite often in the Ember ecosystem but ember-modifier is declared as a dependency for so many addons that I think we might need to do something specific.

With the breaking changes between majors versions v3 and v4 and the number of addons addons that are still shipping with ember-modifier@v3, updating your app's blueprint using ember-cli-update can cause some issues at the point when your app starts to depend on v4.

Between the different package managers fighting and possibly shipping duplicated versions (even among same majors), the different versions all fighting over the same namespace in the amd resolver, and the eager flag changing expected behaviour from under addons feet, the incompatibilities can lead to failed upgrades between ember versions (with very little direction for developers on what they can do to remedy the situation)

It would be highly desirable for v4 version to detect presence of other v3 addon copies and warn users to update their other dependencies or we risk people getting stuck with failed bp upgrades and unhelpful messages and no real path forward unless you're on a technical level advanced enough to not use something like ember-cli-update at all which is not the desired outcome from a batteries included perspective.

[NullVoxPopuli]

A way to do this is to patch release both v3 and v4 to have some sort of globalThis communication. the v4 code is on main, and the v3 code is here https://github.com/ember-modifier/ember-modifier/tree/v3

However, that would not solve the AMD collision, only when multiple copies are present at runtime (a normal webpack, vite, etc thing to allow -- they are a lot more forgiving (they have a pit of success)).

And the v4 version of ember-modifier has no build-time behavior (as it's a v2 addon), so it can't check for the presence of v3 in node code like v1 addons can.

We could maybe add a hard-coded rule/set of logic to https://www.npmjs.com/package/ember-cli-dependency-checker which is in the blueprint, iirc.

[SergeAstapov]

tbh I don't think this worth the effort and compexity for this addon.

Most popular addons I've checked in https://www.npmjs.com/browse/depended/ember-modifier already depend on either v4 or allow v3 || v4 which is not an issue for neither yarn, npm or pnpm to pull the latest.

can you give an example of addons that lack behind and still depend on v3?

[void-mAlex]

this issue is coming from upgrading existing apps

lets take ember-gesture-modifiers	Addon Version	e-modifiers version supported
6.0.1	v4 only
5.x	v4
v4	v3

and ember-scroll-modifiers

Addon Version	e-modifiers version supported
v7.2.0	v4 || v3 <--- happened 2 months ago
v7.0.0	v4
6.0.1	v4
5.x	v3
v4	v3

for both of those stuck on versions 4.x and even today I wouldn't be able to update; to be able to do that would need to deal with not only internal modifiers that would be affected but also any addon or addon of addons that didn't support v4 yet

then you have addons build upon other addons like ember-power-select which in turn forces a particular version of ember-modifier (v4 - but depends on version you're starting from)

so you're suddenly force to be able to upgrade all of your dependencies in one go and deal with all breaking changes in one go and likely your build won't actually work until you get everything right

to make matters worse allowing both v3 and v4 in addons complicates things due to the nature of the breaking change v4 introduced with the eager flag I have not had the time to figure out the fallout of trying to use one of those addons above with the v3 version - I'm hoping ember try is used successfully and there wouldn't be issues

edit: the point I was trying to raise is that doing e-c-u to up your ember version is going to break your build and you won't know it's because you have old addons that pull in e-m which is incompatible and I don't even want to get into doing this with yarn ...

[NullVoxPopuli]

I mean, if you figure out what the path forward is here, you'll make the entire JS ecosystem very happy.

Because... this is a very common problem, and often one of the reasons folks find themselves in "dependency hell"

[void-mAlex]

I mean, if you figure out what the path forward is here, you'll make the entire JS ecosystem very happy.

I've already stated why I believe a path forward here is, tooling to point people to what their issue is and easily identify what they need to do, as it stands only a select few will figure out what's going on with their apps even

as a separate point any addon needs to declare dependency on ^3.2.0 or above in the 3 series which is not what I currently see the trend being: 3.x - this is coming from possibility that package manager will satisfy cuurent dependency requirement with something that is already in the lock file and if it's 3.x you better pray that it's at least 3.2.0

[NullVoxPopuli]

you mean like some addition to an ember-specific version of https://github.com/ef4/are-my-node-modules-messed-up/compare/main...NullVoxPopuli:are-my-node-modules-messed-up:main that checks for hard-coded knowledge like this?

I think it's doable