Peer dependency groups

[Jamesernator]

Currently peer dependencies are fairly limited, one can either require a dependency be present, or can make it optional. However in a number of cases it would be more desirable to have a list of alternative dependencies at least one of which must be present while also still automatically installing the first if none is provided.

The example that encouraged me to open this is this issue on StackBlitz. Essentially one cannot have "esbuild" and "esbuild-wasm" both as potential options for a dependency, but require that at least one is a peer dependency (or automatically installed as per npm 7).

Thinking about though there's actually quite a number of a cases where peer dependency groups would be desirable, as some examples

• Alternatives for fetch (node-fetch/undici/etc)
• Using existing coloring libraries when present (colors/chalk/etc)
• Alternatives for parsers (@babel/parser/acorn/shift/typescript/etc)

As a simple idea for how this could look in package.json:

// snowpack/package.json
{
    "peerDependencies": {
        "esbuild": "99.x",
        "esbuild-wasm": "99.x"
    },
    "peerDependenciesMeta": {
        // Dependencies are still optional
        "esbuild": { "optional": true },
        "esbuild-wasm": { "optional": true }
    },
    "peerDependencyGroups": [
        // Declare that at least one of these is required, if none is given
        // then npm would just download the first by default
        // (when installing peerDependencies automatically is enabled)
        { "alternatives": ["esbuild", "esbuild-wasm"] }
    ]
}

The above proposal also integrates with older versions of npm in the same way that automatic installation of peerDependencies does, in that it won't break older versions of npm. Older versions of npm will simply ignore it and one will need to install at least one of the peer dependencies explictly.

[styfle]

We need something similar for Next.js which relies on SWC (native optionalDependencies but we want a WebAssembly fallback).

Also note, there is a proposal from Yarn to solve a similar problem: yarnpkg/berry#2751