"*" sub-package dependencies create version-mismatch errors

[schvenk]

When reactour's various sub-packages include other sub-packages via their package.jsons (e.g., @reactour/tour including @reactour/utils at package.json:22), they set the version to "*". This means, for example, that if you use v2.13.0 of @reactour/tour, it will still install the latest version of all the other sub-packages.

This was an issue for us because we're still on react-scripts 4, which isn't compatible with the latest versions of reactour. (We may have a workaround but that's another story.)

But our situation aside, I think this is worth fixing because it opens up the possibility of unknown errors in the future when parts of reactour get auto-upgraded in ways that are potentially incompatible.

(Until this is fixed, npm overrides offer a pretty easy workaround.)

[elrumordelaluz]

Thank you @schvenk for pointing this out. There are some problems with @reactour/utils packages build and publishing which is creating all this related errors.

Can you share the npm override workaround in order to be useful to others to temporary fix this? (I think should be usefull also in #497)

[elrumordelaluz]

@schvenk mind testing again with a clean install (rm -rf node_modules yarn.lock package-lock.json? Thanks!

[schvenk]

Yep—tested again with the same result. (This is with @reactour/tour version 2.10.3.) Presumably it wouldn't cause a problem with the latest version since the * will result in properly-aligned versions.

Here's the workaround. In your package.json, in its own top-level section, specify explicit versions for any reactour sub-packages that will be included by other sub-packages. So, a subset of:

  "overrides": {
    "@reactour/utils": "0.3.0",
    "@reactour/popover": "0.4.1",
    "@reactour/mask": "0.5.1",
    "@reactour/tour": "2.10.3"
  }

I chose my versions based on date—that is, they're versions whose release dates are all around the same time. In our case, we only import tour directly, and in fact we can get away without including it in the overrides (since none of the other packages includes it), but it also can't hurt to have it there.

Big risk here is later, when we forget about the overrides, and try to upgrade reactour, and it doesn't work and we don't remember why. In fact, including tour in the overrides, even though not strictly necessary, is probably a good idea for us because then when we try and upgrade it we get an error at upgrade time instead of compile time.

[elrumordelaluz]

Thanks a lot for sharing the overrides, allowing others in the same situation to solve them also!

In another thread (related on this mess) someone shared a solution just updating react-scripts also, in case could be useful.

I will try to understand if there is a way to lock versions of sub-packages for specific version of /tour, inputs welcome in case you know some way.

Thanks again!

[schvenk]

react-scripts: Upgrading that would indeed allow us to use the latest reactour, which would solve the immediate problem but still leave open the possibility of future issues of the same nature. (And at the moment, we have other dependencies locking us into react-scripts 4.)

Locking sub-packages: is it not enough just to specific specific versions in each of your package.json files?

[elrumordelaluz]

Locking sub-packages: is it not enough just to specific specific versions in each of your package.json files?

Will investigate on how to do only on specific versions of @reactour/tour, leaving * for the last version.

thanks again!