3

This question is mostly based on react-admin, hence the tags, but it's probably also useful in other situations.

So we have react-admin which depends on @material-ui/core. This allows me to use Material UI in my own code while implementing the UI without depending on @material-ui/core myself. However, what I can't do is use any kind of help from an IDE (VSCode / Emacs + LSP), e.g. I can't auto-import anything from @material-ui/core.

I consider this behaviour correct and expected, since @material-ui/core is not a dependency of my project. However, I still can use that depedency, so I would like my tools to know that. Adding it as my own dependency is rather ugly, since I'd have to keep versions synchronized to react-admin's, which can be a hassle and kind of defeats the whole point of dependency management. I tried adding @material-ui/core to my peerDependencies, which seems to be quite a bit backwards, but surprisingly works for both VSCode and LSP.

So the question is: which is the correct way to re-use sub-dependencies without adding a bunch of unneeded dependencies to my project?

Nikolai Prokoschenko
  • 8,465
  • 11
  • 58
  • 97
  • Having surprise dependencies (not declared) is unexpected and is therefore MUCH MORE UGLIER than adding the dependency directly. On the contrary, adding `@material-ui/core` as a dependency to your code is **beautiful** (which is the opposite of ugly) since it allows maintainers to know what is being used as well as what version is being used by just looking at package.json – slebetman Sep 06 '21 at 04:30

1 Answers1

1

At the app's point of view, generally, if you want to use @material-ui/core then you should put it in to your dependencies. no idea why you think it is 'ugly'

App shouldn't have peerDeps. peerDeps is designed to be used by plugin/library.

Wayne Mao
  • 419
  • 5
  • 9