Consider removing all `peerDependencies`

Which package is this issue related to?

🌐 All the things

Describe your issue

When using packages with a React and Less version we have a peerDependency on the Less version from the React version. A lot of Less packages also have a peerDependency on @sb1/ffe-core (even some React packages, like accordion do this). These tend to get out of sync, as it seems Lerna ignores them. This again creates a whole set of warnings on npm install that this and that peer dependency is missing. Some of these peerDependency requirements may also conflict for absolutely no reason.

The peerDependencies were originally added to give some kind of hint that you need this other package for the package to work as intended. For React and Less pairs I feel this is a given, and the peerDependencies just add noise.

What I’m suggesting is that we remove it all.

@sb1/ffe-core is a bit tricky. Maybe now that we use Lerna we could instead make @sb1/ffe-core a direct dependency? This way we:

• Can remove peerDependencies (👍)
• A breaking change in core also triggers a major release of all dependencies, regardless of feature use (👍 / 👎 )

[ivarni]

FWIW the reason we decided to use peer-deps over regular deps + a less-loader was to avoid a situation were a consumer of N different react-packages ended up with anywhere from 2 to N different versions of i.e. the ffe-core less package.

The peer-dep was meant to indicate which versions the different intemediate modules relied on and basically act as a red flag once a consumer put themselves in a situation where they could not possibly be able to pick the correct less-package version, in which case they’d need go to make a PR to bring offending packages up to their required versions.

To move the cognitive load of this away from consumers, maybe a requirement for someone creating a breaking version of any one ffe module would should be to find and update all its downstream modules as well?

[selbekk]

Me and @wkillerud had a quick talk about this. Basically the worry about approach number 2 is that for people (like @wkillerud and myself) that would end up using both the React component and the LESS packages directly, this would lead to a lot of trouble if not handled with some care.

Now how would you ever end up in a situation like that, you say? Well in our case, we are migrating a large application from backbone-marionette to React piece by piece, and we currently have about ~half of the code migrated. If we were to go with approach number two, we would need to keep a very close eye on changes in the React package, which then would include a potentially breaking LESS file (requiring changes in the DOM structure for example).

We kind of concluded that those consumers would be left to their own devices. We cannot optimize our workflow for a very small subset of consumers - even if we are one of them.