Does anyone know how the pulumi cli decides what version of a plugin it needs? For aws, it doesn't seem to be determined by the version of @pulumi/aws in my package.json. I've got a lot of older versions of the plugin in my cache directory and it bothers me that I can't delete them without pulumi mysteriously downloading them why I run certain stacks.

drwx------  6 kenji  staff   192B Jan  6 13:57 resource-aws-v5.35.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 13:57 resource-aws-v5.35.0.lock
drwx------  6 kenji  staff   192B Jan  6 14:03 resource-aws-v5.42.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:03 resource-aws-v5.42.0.lock
drwx------  6 kenji  staff   192B Jan  8 09:23 resource-aws-v6.13.2/
-rw-r--r--  1 kenji  staff     0B Jan  8 09:23 resource-aws-v6.13.2.lock
drwx------  6 kenji  staff   192B Jan 10 12:13 resource-aws-v6.13.3/
-rw-r--r--  1 kenji  staff     0B Jan 10 12:13 resource-aws-v6.13.3.lock
drwx------  6 kenji  staff   192B Jan  6 14:31 resource-aws-v6.14.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:31 resource-aws-v6.14.0.lock
drwx------  6 kenji  staff   192B Jan  6 14:34 resource-aws-v6.15.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:34 resource-aws-v6.15.0.lock
drwx------  6 kenji  staff   192B Jan  6 14:27 resource-aws-v6.17.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 14:27 resource-aws-v6.17.0.lock
drwx------  6 kenji  staff   192B Jan  9 18:18 resource-aws-v6.18.0/
-rw-r--r--  1 kenji  staff     0B Jan  9 18:18 resource-aws-v6.18.0.lock
drwx------  6 kenji  staff   192B Jan  9 18:35 resource-aws-v6.3.0/
-rw-r--r--  1 kenji  staff     0B Jan  9 18:35 resource-aws-v6.3.0.lock
drwx------  6 kenji  staff   192B Jan  6 13:35 resource-aws-v6.4.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 13:35 resource-aws-v6.4.0.lock
drwx------  6 kenji  staff   192B Jan  8 09:45 resource-aws-v6.8.0/
-rw-r--r--  1 kenji  staff     0B Jan  8 09:45 resource-aws-v6.8.0.lock
drwx------  6 kenji  staff   192B Jan  6 12:48 resource-aws-v6.9.0/
-rw-r--r--  1 kenji  staff     0B Jan  6 12:48 resource-aws-v6.9.0.lock

What is the version in your

package.json

? Short story is yes, it's determined by the version in your

package.json

Here's an example of pulumi installing an old version of resource-aws, even when it says it should be using a new one

if you refresh/preview an older stack that was deployed with an older version, i believe it pulls it back in. If you were to deploy it again with the newer version specified, then i think it will no longer want/need the old one

tried that, had no effect

@fresh-spring-82225

awsx

is a component package which has its own dependency on the core

aws

package. Not so long ago, I extended our docs a bit with some more info: https://www.pulumi.com/docs/languages-sdks/javascript/#dependencies-on-provider-packages-within-component-packages You also have to make a distinction between

pulumi

operations which evaluate your infrastructure code and operations which use only the state information. This is how

pulumi

CLI acts in general (which is still a simplified representation): • `preview`: Pulumi CLI will use the new plugin version from your NodeJS

package.json

to read the existing resource state, calculate the diff & display the needed resource changes. The new version is not saved to state. • `refresh`: Pulumi CLI doesn't execute the user program, so will use the plugin version recorded in the state to read the resource state, and communicate with the real API to compare. When changes are accepted, some property values can be updated but no change in the version of the plugin binary will happen. • `up`: these proposed changes are applied using the new version of the provider. When some resources are scheduled for deletion, this will be done using the old version of the plugin. Other resource changes are handled using the new version of the plugin. The resource changes, together with the new plugin version, are now saved in the state. • `destroy`: Pulumi CLI doesn't execute the user program, hence the plugin version from the state is used to delete the resources. All state is deleted at the end. As you can read, multiple versions can still be at play when you just upgraded a provider version.

@limited-rainbow-51650 I can understand some of the logic behind this decision, but is there a way of forcing the use of single defined version or bumping/upgrading ‘legacy’ versions used in the past to a defined version/latest? I see the use of “^” in the link above, but that appears to be $latest (pls confirm either way). Scenario is when I want to remove the legacy versions from the env. Example when a specific version has security vulnerabilities etc. How do I force ‘only use x.y.z version’? Apologies if this is a dumb question - I’m a noob…

@limited-rainbow-51650 I still don't fully understand, but I wanted to thank you for your response anyway