Mismatching version for `@aws-solutions-constructs`

[garysassano]

After doing a npx projen upgrade, I ended up with this situation:

So I added the extra dependecies to my .projenrc.ts and run npx projen, thinking it would automatically pull the latest version from npm and match the other two @aws-solutions-constructs modules:

But nope, projen installed the older version instead, so the issue persisted:

I had to manually run the following to fix the issue:

pnpm add @aws-solutions-constructs/core@latest @aws-solutions-constructs/resources@latest

I don't understand why I've never encounered this issue with modules from @aws-sdk, which always get updated with synced version, whereas for @aws-solutions-constructs it seems to behave differently.

[mrgrain]

This doesn't seem like a projen issue, but one with the dependencies you are using.

Projen doesn't install anything, it generates a package.json and might enforce a certain version constraint. Then your package manager is installing software.

Since projen core doesn't have a project using @aws-solutions-constructs, the issue must be somewhere else.

FWIW managing and upgrading peer dependencies seems to be hard for package managers.

[garysassano]

After fixing the issue of updating the deps to the right version, I could remove @aws-solutions-constructs/core and @aws-solutions-constructs/resources.

My actual question was: shouldn't npx projen upgrade natively handle upgrading modules from the @aws-solutions-constructs namespace correctly?

[mrgrain]

Projen uses a third party tool and your package manager for upgrading packages. If you can post the starting package.jsonand lock file or at least the full output of the upgrade command, I might be able to help you debug.

But again, upgrading with peer dependency constraints is a somewhat complicated task. It requires the package that's defining the constraint to be downloaded for the new peer dependency constraint to be extracted. I've definitely seen ncu (the tool projen uses) struggle with that.

[dkershner6]

We run into this same constraint with various libraries, especially @aws-sdk and @smithy libraries. We created a projen construct that enforces them all to be the same (except for the weird ones with different versioning, and it has set versions for those).

Then you can just lock and upgrade all together, as required, but I agree with momo that this should not be a concern of projen core.