Hi all, I’m struggling with the upgrade from 0.69 ...
# sst
d
Hi all, I’m struggling with the upgrade from 0.69 to 1.0.1. The new Auth construct is tripping me up. Because the SST Auth construct doesn’t offer the same level of customization as the CDK does (my config looks like https://serverless-stack.com/examples/how-to-add-google-login-to-your-cognito-user-pool.html). So I think I need to import an existing userPool that I create using the CDK: https://docs.serverless-stack.com/constructs/Auth#importing-an-existing-user-pool However, I can’t make typescript happy doing this.
Type 'IUserPool' is not assignable to type 'UserPoolProps | IUserPool'.
Type 'import("/Users/davidmartin/dev/node/cats/shopcats/node_modules/aws-cdk-lib/aws-cognito/lib/user-pool").IUserPool' is not assignable to type 'import("/Users/davidmartin/dev/node/cats/shopcats/node_modules/@serverless-stack/resources/node_modules/aws-cdk-lib/aws-cognito/lib/user-pool").IUserPool'.
I’m not sure what I need to do about this, if anything. Clearly they’re both IUserPool interfaces, just imported from different locations. Should I just @ts-ignore?
t
this sometimes happens if there's a mistmatch with where node_modules is resolving from
can you nuke your node_modules and try again? I can see in your error it's in two places
d
Ok let me finish eating my croissant sandwich and I will
t
think 1.0.2 requires "aws-cdk-lib": "2.20.0",
d
that seems to have worked. man, you know i love y’all at SST, but saying this is a 15 minute upgrade seems like an underestimation.
if i switch from the class components with ids to the functional components without ids, what will happen to my existing deployed stacks? how will SST know which stack to update without the ids i sent from the classes?
// from import { MyStack } from “./MyStack”; new MyStack(app, “my-stack”); // to import { MyStack } from “./MyStack”; app.stack(MyStack);
t
you can manually specify the id with
app.stack(MyStack, { id: "my-stack"})
d
ok. i’m totally up and running on 1.0.1 now including making all my stacks functional with nice cross referencing. this is sick. way better config. way more maintainable.
the auth stack could use a little more polish. happy to give feedback if you’re interested. tl;dr: the SST Auth construct should accept more configuration parameters for identity providers to be more useful. for example, i need to send more than just the clientId to google, i need to send: clientId, clientSecret, attributeMapping and scopes. this is true for the other federated identity providers as well. i kept my existing CDK config because the sst construct doesn’t accept those. but it’s all good. things are working well.