Question regarding environment variables… If I add...
# sst
a
Question regarding environment variables… If I add environment variables on the API construct, and then down the line, I add a new route with
addRoute
, which instances a
Function
construct, and also defines new environment variables… Are the first ones replaced by the second ones? or both are merged?
Ah, I can’t do what I want:
Copy code
Error: The "defaultFunctionProps" cannot be applied if an instance of a Function construct is passed in. Make sure to define all the routes using FunctionProps, so the Api construct can apply the "defaultFunctionProps" to them.
f
Yeah, can you create the function inline instead of creating one and then passing it in?
In that case, the environments will be merged
a
But inline doesn’t have the
environment
?
I mean the attribute is not there?
Or maybe I did it wrong.
Humm, looks like is there.
Not sure why the code completition is not showing it.
f
Are you using VS Code?
a
Yeah.
I think there is a mix of types.
[key: string]: FunctionDefinition | ApiFunctionRouteProps | ApiHttpRouteProps | ApiAlbRouteProps;
f
Yeah, (let me cc @thdxr he’s got some ideas on how to fix this up his sleeves). Yeah you should be able to specify
environment
a
Ok cool, thank you, you saved me lot of time 🙂
t
This has to do with ts not being able to infer exactly what you're trying to do in the moment of auto completion. But if you type environment it won't error when checking. This is a limitation of unions without a discriminator in typescript
There's tradeoffs with that approach and I don't have a strong opinion that it should be changed
a
Yeah.
This is what confuses me a lot about unions.
I mean I like it from TS… but sometimes is not smart enough .
Or VS is not smart or something is not smart.
t
Yeah I think intuitively people expect ts to show all the combined fields. But it actually can only show common fields until you hint it enough
a
Yeah.
t
I can tell you a long story on why it has to be this way in ts but it's boring
a
Hahaha.
Well good I’m not the only one noticing this 😂 .
t
In my own code I tend to do stuff like this
Copy code
type Rectangle = {
  kind: "square";
  width: number;
  height: number;
};

type Circle = {
  kind: "circle";
  radius: number;
};

type Shape = Rectangle | Circle

function test(s: Shape) {
  console.log(s.height) // type error
  if (s.kind === "square") {
    s.height // valid
  }
}
as soon as you specify kind, autocomplete can give you the exact shape of the data. It's really productive but I don't see a good way to use this approach in SST
a
Yeah.
Sad.