Pin dependency versions on release

[mattrunyon]

Provide a general summary of the feature here

@adobe/react-spectrum package lists dependencies on the other spectrum packages with ^x.y.z notation. This means installing a specific version of @adobe/react-spectrum does not provide a consistent install every time and there are dozens of dependencies which can change. It also makes it tedious to downgrade if needed.

🤔 Expected Behavior?

npm install @adobe/react-spectrum@x.y.z in a fresh results in the same package-lock and always uses the same versions of all adobe packages.

😯 Current Behavior

The install will end up with the wrapper package downgraded, but all the other spectrum packages at their latest version within the same major version.

💁 Possible Solution

Pin the versions on release so the distributed package.json files do not list ^x.y.z as the versions

🔦 Context

#6241 fixes an issue with combobox, but has not been released yet. We discovered this after upgrading our package-lock.json. Downgrading @adobe/react-spectrum or installing a specific version does not work around the issue because the @react-aria/overlays package is the offender and a dependency several levels down. We had to add 11 overrides just to get that version pinned properly since package-lock.json had updated all of the previous versions and the newer versions are valid according to the older version's version ranges.

- @adobe/react-spectrum 3.33.1
  - @react-spectrum/combobox ^3.12.1(3.12.3 previously installed and doesn't downgrade)
    - @react-aria/combobox (uses @react-spectrum/combobox 3.12.3 version minimum, not 3.12.1)
      - @react-aria/overlays (the package we need to downgrade. Also need to downgrade everything that consumes it to prevent newer versions since the parent has a higher minimum version listed)

💻 Examples

No response

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[JamesXNelson]

I believe pinning these versions would also reduce gradle-related build errors from npm shifting dependencies.

+1

[snowystinger]

related RFC https://github.com/adobe/react-spectrum/blob/main/rfcs/2019-v3-versioning.md

[devongovett]

The problem with pinning is that it's really easy to get duplicate copies of packages. If an app depends on one version of RSP, and it uses libraries with shared components that depend on another, the shared dependencies will currently be deduplicated, resolving to the highest compatible semver version. If RSP pinned its dependencies, this would no longer happen, and you'd get multiple different versions of the shared dependencies. This can cause problems like context not matching resulting in runtime errors, along with larger bundle sizes. I believe we tried this approach early in the life of v3, and switched to caret ranges due to these issues.