^ seems to be working now. blew up node_modules.
# sst
m
^ seems to be working now. blew up node_modules.
f
hey @Mike McCall did u get it to work?
m
Yeah, reading deeper in the error it was mismatched types (same type reference 🤷‍♂️ ). I deleted the entire node modules dir and did a reinstall. It seems like a version mismatch, but the versions were the same…
f
Can you share a snippet of the error?
m
I do not have the exact error anymore but it was close to this: https://github.com/aws/aws-cdk/issues/8211
types of parameter are incompatible.
f
Do you remember if the error comes from the CDK code or SST code?
m
Sorry I’m not being much help at this point… So the message saying it expected IUserPool instead of UserPool was from sst. But I THINK that was a bit misleading because the incompatible parameter types from cdk.
f
Got it. My hunch is that you have the
aws-cognito
dependency in your package.json, and you are using it to import the userpool. And
sst.AppSyncApi
also has a
aws-cognito
module in its package.json. And depending on how npm installs them, there could be 2 different instances of
aws-cognito
in your node_modules.
And doing a fresh install usually solves that.
m
Yup, it’s also using yarn workspaces.
BTW is there a good way to see what version sst expects?
f
In this case, they are probably of the same version. Your node_modules probably looked like:
Copy code
node_modules/
  @aws-cdk/
    aws-cognito v1.94.1
  @serverless-stack
    @aws-cdk/
      aws-cognito v1.94.1
If the user pool is created using 1
aws-cognito
import, and then the other
aws-cognito
try to check its type, it results in an type error
m
ahh ok
f
But yeah to answer your question, SST will print out a warning if there is a version mismatch with the version that is mismatched.
This type of issues will be resolved in CDK v2. SST will be able to include
aws-cdk
as a peerDependency. So there should never be multiple instances of the same CDK classes in your node_modules.
m
sweet, cdk is moving monolith structure (like sst)
f
yup yup!