<@UB9JVTW07>?
# general
b
@lemon-spoon-91807?
l
Let's continue this here @proud-alarm-92546
@broad-dog-22463 This is awsx, not aws.
b
so it's not related to the same thing we just spoke about?
l
Nope 🙂
b
phew!
p
heh
l
So this is easily fixable. but i need a little more info @proud-alarm-92546
can you show me the code you have that's instantiating the ApplicationLoadBalancer
p
Copy code
// setup the loadbalancer.
const alb = new awsx.elasticloadbalancingv2.ApplicationLoadBalancer(namePrefix+"alb", {
  name: namePrefix+"alb",
  // tags: { Name:namePrefix+"alb" },
  vpc: cluster.vpc,
  external: true,
  // can't type this right yet.
  // ipAddressType: config.ipAddressType,
  // longer term we should probably be DEFINING what sg we create in our code if we create/maintain one?
  securityGroups: cluster.securityGroups,
  subnets: cluster.vpc.publicSubnetIds
});
l
and where is
config.ipAddressType
?
p
Copy code
// allow setting to `ipv4` in the event ds isn't capable on the vpc
export const ipAddressType = config.get("ipAddressType") || "dualstack";
(in config.ts)
l
right. ok. simplish solution
p
typescript is pretty far from home for me, but since the libs (and most of the examples) were all written in it, it seemed saner to start there than directly in js and try to convert without working stuff. 🙂
l
and TS is doing the right thing here.
p
sure - I just have no idea how to make this that kind of type (also: why it cant just be a string)
l
because it's quite possible you might do something like
pulumi config set ipAddressType boatymcboatface
p
right - all config.*'s end up being strings (unless bool/list, etc based on how you get them).
l
so what you want is, i believe, this:
export const ipAddressType = config.require<"dualstack" | "ipv4">("ipAddressType", { allowedValues: [ "dualstack,  "ipv4" ] });
a few benefts
1. this is now typesafe
2. this will throw at runtime if you use boatymcboatface
p
gotcha, thanks.
l
alternatively, if you don't care
then on the line:
ipAddressType: config.ipAddressType,
you can just do
ipAddressType: <Input<"dualstack">>config.ipAddressType
this is basically just saying "shut up ts, i know what i'm doing"
it seemed saner to start there than directly in js and try to convert without working stuff. 🙂
yeah, this is esp. true as we rely a lot on type-system checks. so we'll happy chug along with just raw JS until you get into a bad place later. where the type system of TS would have caught it earlier
so would def recommend TS-first
p
the types make using this stuff -insanely- hard though. you have to have a significant amount of internal knowledge before it's consumable. how does the python side of this handle this kind of thing?
l
how does the python side of this handle this kind of thing?
0 protection
write whatever you want. it may or may not work.
p
when presenting this to the team of node developers I'm building it for, they pretty much immediately went to "please convert to js, we hate typescript." 🙂
l
i'm guessing you come from a more dynamic-language background?
that's interesting (and a first) where i've heard that
sentiment of TS in the JS community tends to be fairly high
p
I'm a shell guy natively, have worked in literally everything, but probably more ruby than anything else.
l
so i don't know how representative that is
i'll count ruby as "highly dynamic"
i mean ,in a very real sense, TS jst caught a bug
because it's saying "you are allowing a bad value to flow through here'
p
oh, sure, but only because the input wasn't just a allowed to be a string... 🙂
l
now, if that raises to the "i'm ok being told that now" or "i owuld be ok with that crashing" could be a personal preference.
right. but that's the value. if it was just a string, people could pass bad values in.
(And we actually have that issue elsewhere. so we try to push for more typesafety)
if you don't want that, we have no problem with you using straight JS 🙂
p
right, but test logic for handling that is (imo) way saner than trying to go figure out how to re-type your string input.
l
this is philosophical
p
oh for sure.
l
and usually the divide between the static camp andthe dynamic camp
pulumi's TS lib falls into the TS way of thinking about things.
where static is preferred.
p
to me, it's more about having to learn internal knowledge of the library etc vs just using it.
l
but it's just a JS lib at the end of the day. so if types aren't pleasant, you don't have to use them.
i guess i would say: this isn't internal knowledge
this is the library stating externally: here's how to use me
if it didn't state this, you wouldn't knwo (except maybe through docs)
p
gotcha
l
TS simply acts as a way or us to both doc this huge surface area and have a tool that tells you up front if you're violating things
p
thanks for the help!
l
yup yup!
feel free to ping at any time!
p
how would I give this one a default value of
dualstack
?
Copy code
export const ipAddressType = config.get<"dualstack" | "ipv4">("ipAddressType", { allowedValues: [ "dualstack",  "ipv4" ] })
I'm sure there's a mechanism but ts's type setting mechanisms are as clear as mud to me.
l
just add
|| "dualstack"
to the end
p
...and that wouldn't result it in being a string?
now -that- baffles me. 🙂
l
oh, that makes it into a string?
ok. just do this:
export const ipAddressType <"dualstack">(config.get("ipAddressType", { allowedValues: [ "dualstack",  "ipv4" ] }) || "dualstack");
annoying
sorry about that
will have to make a better helper here.
p
thanks@!
ok the original that I thought would make it a string seemed to be the winner.
Copy code
export const ipAddressType = config.get<"dualstack" | "ipv4">("ipAddressType", { allowedValues: [ "dualstack",  "ipv4" ] } ) || "dualstack" ;
now have a dualstack lb
the other one gave an any error. 🙂
Copy code
// export const ipAddressType <"dualstack">(config.get("ipAddressType", { allowedValues: [ "dualstack",  "ipv4" ] }) || "dualstack");
    // config.ts(35,28): error TS1005: ',' expected.
    // config.ts(35,14): error TS7005: Variable 'ipAddressType' implicitly has an 'any' type.
took me a while to track down a missing " and ), doh.