Spectrum component dependency issues

[carolframpton]

In our packages.json we had our react-aria/interactions pinned at "@react-aria/interactions": "3.4.0".

We recently upgraded from "@react-spectrum/table": "3.0.0-beta.0" to "@react-spectrum/table": "3.0.0-beta.1". This new version lists "@react-aria/interactions": "3.5.0" as a dependency.

We got no warning from npm and it took awhile to figure out what broke.

At our scrum it was suggested that in packages.json you should be listing table's dependencies as peerDependencies rather than dependencies so npm will complain.

This is not the first time we've lost a good deal of time due to a Spectrum dependency issue and we'd like to try to figure out how to avoid anymore going forward.

Thoughts?

[snowystinger]

First, thank you for coming with an idea. I think we'd need to list it both as a peerDependency and dependency, would that defeat the purpose of listing it as a peer though?
I think we still need it as a dependency so that people can just install it on it's own and have everything they need to get going, but maybe this could be discussed more

[boag]

I don't think it does, though I may be mistaken. The goal of having it as a peer dependency is for the client build to fail when attempting to run npm i. Right now, we're observing updates to the spectrum component dependencies (in this case the table package) do not enforce the relevant version in the client.

Instead, what likely happens is that webpack brings in myClient/node_modules/@react-spectrum/table/node_modules/@react-aria/interactions as well as myClient/node_modules/@react-aria/interactions, with the lower one likely winning at runtime.

I believe adding the additional reference to the peerDependencies would result in only a single version, with the npm i explicitly failing if we haven't rev'd our version to match what the library needs.

[snowystinger]

I don't think that either one wins during runtime, I suspect that if you look in your bundle analyzer, you'll see both of them. This causes React's Context to fail because one module is used to create the Context and a different one to retrieve it. Since they aren't the same, the consumer thinks there is nothing on the Context for it.

Peer deps also will not cause a failure, only a warning, and will not cause resolution to happen any differently. What I don't know is if we include it as both peerDep and dep, will the dep fulfill the peerDep and cause the warning to not show?

I don't think we want to get rid of the deps.

There are tools to help you quickly determine if you have duplicates of any package installed, which is a good thing to check in a UI application where it matters a lot. If you use yarn you could get the tool yarn-deduplicate and run the command yarn-deduplicate --scopes @adobe @react-spectrum @react-aria @react-stately @internationalized @react-types @spectrum-icons —list —fail
you could even put this into your build pipeline so it fails for PR's or anything else

[skyboyer]

In my project we run exactly into multiple instances when Consumer inside of "useButton" does not communicate to Provider from Overlays. We consume @react-aria/buttons indirectly by used 3rd party UI controls' package and pick @react-aria/interactions directly to make overlay/modal. 3rd party package released new version that relied on newer @react-aria/buttons so got newer @react-aria/interactions.

After finding out root cause I've tried npm dedupe but it did nothing. Not sure - why. Resolved by uninstalling both packages and installing them again(but in specific ordering), this way have got only single instance.

@showystinger, thank you for advice with yarn-dedupe. Will try to integrate into CI, if moving packages with context into peerDependencies is not expected.