A few months back, I attempted to use a module of mine that had some peer dependencies which were not loaded by runkit. I thought this was such a drawback that I stopped declaring peer dependencies and re-published my module. However, peer dependencies are becoming more popular because they can reduce the size of node_modules. Installing missing peer dependencies is a new feature of npm 7. Adding dependencies to a brief notebook example isn’t convenient. Does Runkit install peer dependencies now? If not, will it ever?
Hi @terrisgit,
Peer dependencies are fairly challenging as they contain a number of weird edge cases, and we currently don’t “automatically” install them since there’s no obvious way to manually resolve any of these issues in our current UI. We have a number of UI changes coming out that would resolve this however, and thus allow us to more easily implement strategies that work “most of the time” while allowing users to resolve any conflicts simply.
For a bit of context, a peer dependency must be a peer of the dependency in question (vs. a dependency internal to it, in its sub-node_modules folder), as it must be equally accessible by any other package that lists it as a peer dependency. The most common examples are of course plugins (like React or babel plugins). For example, both @babel/plugin-transform-parameters and
@babel/plugin-transform-react-jsx expect @babel/core to be present. If you however require the first one today, and then come back to the notebook a month from now and require the second one, any number of conflicts might take place. The time difference could mean that they now want very different versions of @babel/core to be present, at which point we either need to either make a best attempt at resolving the conflict (either by choosing an earlier version of the new package you are installing that is OK with the older versions of everything else you are using, or by automatically upgrading the previous already required packages so that they agree with the new requirements), or by perhaps asking the user. Situations like this can arise even without the timing problem, two packages could rely on conflicting peer dependencies even if required on the same day. A CLI environment like npm is allowed to just fail and print and error/warning, or interactively ask you, but we again need to find a way to accommodate for this in our UI.
I know it is frustrating that these complicated cases block the “simple” case of “I’m just requiring one package, I don’t want to have to write require before it when it would just work since it’s just one package,” but on our end it would necessarily create a mountain of these issues as people try to do more stuff. That being said, we are actively working on a solution to this, as I mentioned above, with a better UI for managing the dependencies we automatically choose in general that will give us more options for these situations.