Consider peerDependencies for provider SDK to Pulumi Core SDK dependency in Node

[t0yv0]

Going from:

https://github.com/pulumi/pulumi-aws/blob/master/sdk/nodejs/package.json#L16C5-L16C38

To a peerDependency.

TBD. pro/con? Is it breaking (likely yes).

[t0yv0]

Prior art: pulumi/pulumi#3090

[guineveresaenger]

What are peerDependencies: https://nodejs.org/en/blog/npm/peer-dependencies

Sounds like a big con would be that manual intervention would have to happen on npm install if the dependency doesn't exist?

[t0yv0]

Was just jotting this down from standup convo, I need to read up on peerDependencies. Some more context why this came up is that in pulumi/pulumi-aws-apigateway#178 YARN linked two versions of '@pulumi/pulumiinto the provider build which made if fail with a very obscure error. We're going to solve this withyarn deduplicate` but it was suggested that peerDependencies could be another way.

[t0yv0]

Yeah the article explains it well I think. The suggestion here would be to treat @pulumi/aws SDK as a "plugin" that requests to be used with a certain range of @pulumi/pulumi versions by a peer dependency but not actually depend on it directly to avoid grabbing its own copy. So if that were done, the issue with pulumi-aws-apigateway having two copies of @pulumi/pulumi would not have occurred.

However @flostadler mentioned that moving from a direct dependency to a peer dependency is a breaking change, though I've not figured out why yet.

[t0yv0]

New related failure: https://github.com/pulumi/pulumi-service/pull/24879

Here two copies of @pulumi/aws are selected for the same program - one directly and one via @pulumi/awsx and they end up not being compatible causing type checking failure.

This presumably would not happen if https://github.com/pulumi/pulumi-awsx/blob/1cb31f94c5af15eb25bfeb77e17aef8d7f6dc09d/awsx/package.json#L27 was a peerDependency instead of a direct dependency.