Unable to install an older version of Victory due to carets in internal versions

[tuncaulubilge]

Questions

Checklist

• [x] I have read through the FAQ and Guides

• [x] I am using the latest version of Victory

• [x] I've searched open issues to make sure I'm not opening a duplicate issue

Tech

Using Yarn v1 (1.22.18)

The Problem

We need to use an older version of Victory Native but we are unable to do so due to the carets in internal package versions.

Even if we pin the version of victory-native to a certain version (lets say 36.5.2), we still end up with v36.5.3 of all the other victory sub-packages, such as victory, victory-core, victory-line etc. This is due to the usages of carets in version definitions of victory-native's package.json: https://github.com/FormidableLabs/victory/blob/main/packages/victory-native/package.json#L26-L52

Expected Behaviour

We would expect the packages to use pinned versions of all the internal dependencies to other victory packages, so if we pin a version to a certain number, all the other sub-packages would use the same version as well. Currently, this is not possible.

Why do we need to pin the versions?

We have noticed recently that a minor version bump (from 36.4 to 36.5 iirc), have introduced API changes in victory, which was breaking for us. Also, some recent changes on 36.5.3 does require us to have the newer version of Typescript, which is not a migration we want to take on right away.

Can we not rely on yarn.lock or resolutions in yarn?

Short answer is no. We have a multi-repo architecture so this would require us to incur a huge tech debt across all the repos, adding 20+ resolutions to each repo for every victory package, which is not scalable in terms of maintenance.

[gksander]

Hi @tuncaulubilge – do you recall what sort of (breaking) API changes you noticed from the 36.4 → 36.5 bump? Also, what specific version of victory-native is most appropriate for your use-case?

We're currently thinking about:

1. Should we be version-pinning in victory-native moving forward?
2. Even if we version-pin moving forward, that doesn't help you out much since you're limited to <36.5.3 anyways. Also thinking about how we could produce a patch/tagged release to help in your situation.

[tuncaulubilge]

Hi @gksander, I believe the breaking change was a typescript error for us. I've just checked 36.6.0 and the issue seems to be resolved 🎉 (by this PR https://github.com/FormidableLabs/victory/pull/2363), so we should be able to move to 36.6.0 right away.

I'd still highly recommend introducing version-pinning on the next version, as the current setup doesn't allow us to use an older version of victory. As you said, this wouldn't resolve the problem on the existing version but that's okay as we got a stable release now.

[tuncaulubilge]

@gksander I have created a PR to address this issue and remove all the carets: https://github.com/FormidableLabs/victory/pull/2424

Version bumps are handled by changesets/cli which will follow the new format automatically.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.