peerDependencies are not handled correctly about midgard-yarn-strict HOT 3 OPEN

However, @fluentui/style-utilities doesn't implement them in the parent child sense.

And this has perfect sense 🐱

To clarify, @fluentui/style-utilities does not use react or react-dom, so it should not depend on it either in dependencies or peerDependencies.

What MYS sees as the solution here is to forward them as "peerDependencies" instead of implementing them as "dependencies".

I would like to see an example there 🐱 In meantime, I can share some expectations on how it could work ⬇️

Let's use @fluentui/react-components as an example as the issue started with it. Unlike your example, I think that graph should start in a reverse order:

flowchart LR
 TOKENS("`@fluentui/tokens
    _peerDependencies: {}_
    `")
    THEME("`@fluentui/react-theme
    _peerDependencies: {}_
    `")
    MENU("`@fluentui/react-menu
    peerDependencies: {'react', 'react-dom'}
    `")
    SELECTOR("`@fluentui/react-context-selector
    peerDependencies: {'react', 'react-dom', 'scheduler'}
    `")
    COMPONENTS("`@fluentui/react-components`")

    classDef align text-align:left

    TOKENS:::align --> THEME:::align --> MENU:::align
    SELECTOR:::align --> MENU
    MENU --> COMPONENTS
    COMPONENTS --> APP[app-pkg]

The branch with @fluentui/tokens & @fluentui/react-theme can be ignored as it does not have dependencies.

The base principle:

• If package has matching dependencies in peerDependencies - they SHOULD satisfy the declared range
• If package has matching dependencies in dependencies - peerDependencies SHOULD be merged and bubble up
• If package has no matching dependencies in dependencies & peerDependencies - peerDependencies SHOULD bubble up

The example:

1. @fluentui/react-context-selector declares peerDependencies, they should be resolved on @fluentui/react-menu

• react is present is both package.json#peerDependencies, range matches, bubble up 🆙
• react-dom is present is both package.json#peerDependencies, range matches, bubble up 🆙
• scheduler is not present in @fluentui/react-menu#dependencies & @fluentui/react-menu#peerDependencies, should bubble up 🆙

2. @fluentui/react-menu declares peerDependencies + got scheduler, they should be resolved on @fluentui/react-components

• react is present is both package.json#peerDependencies, range matches, bubble up 🆙
• react-dom is present is both package.json#peerDependencies, range matches, bubble up 🆙
• scheduler is not present is @fluentui/react-components#dependencies & @fluentui/react-components#peerDependencies, should bubble up 🆙

3. @fluentui/react-components declares peerDependencies + got scheduler, they should be resolved on app-pkg

• react is present is app-pkg#dependencies ✅
• react-dom is present is app-pkg#dependencies ✅
• scheduler is not present is app-pkg#dependencies, break install 🔴

from midgard-yarn-strict.

PNPM will also not throw errors when peer depenencies are not forwarded up the dep tree https://github.com/ling1726/pnpm-peer-deps FYI @sjwilczynski

from midgard-yarn-strict.

pnpm treats peers as regular dependencies from my understanding...

So, here's how I think I view things... Midgard Yarn Strict definitely is the most strict of all the above package managers, for better or worse.

If you look at the above image, I think the issue MYS has is that...

An app takes a dependency on @fluentui/react.

@fluentui/react has peerDeps on react, react-dom, @types/react and @types/react-dom.

Ok, cool so far, but @fluentui/style-utilities depends on @fluentui/theme, and here's where things get interesting.

@fluentui/theme also has peerDeps on react, react-dom, @types/react and @types/react-dom.

However, @fluentui/style-utilities doesn't implement them in the parent child sense.

What MYS sees as the solution here is to forward them as "peerDependencies" instead of implementing them as "dependencies".

That's just how the current MYS algorithm views the world.

We've investigated the idea of changing the algorithm a bit to look and see if any parent has correctly implemented the peers, and allowing them to point to the parent, but haven't gotten around to a very performant way to do that.

I'd very much love to have an open dialog and conversation around this as this is definitely a pain point for us too. :)

from midgard-yarn-strict.