SST: 1.2.18 CDK: 2.24.0

basically just an out of the box SST app with

npm init sst

, and no other modifications, and an out of the box seed setup as well, that detected my sst.json file

it just occurred to me this is https://github.com/aws/constructs and not explicitly an sst package, they must have broken something

the application does run just fine locally

Hey I figured this out we needed to set

before_compile:
  - n 14.19.3

in the seed.yml file. I am not sure why but out of the box it was using 14.15.4 and not the latest node 14.x.x is all. Explicitely setting the node version in the yml was able to satisfy the constraints on constructs

Now it seems the ideal behavior is to keep the runtime versions to the latest, and have ppl pin to an older version if their build breaks.

@Frank I can see why that would be a concern. I'd say that if it uses 14 out of the box, just assume 14.x.x makes the most sense. A new user would be surprised to see it use some specific version in the middle of the range. As for existing users, I could see some sort of scaffold (like you are doing with sst) to pin the seed.run the project at the moment of creation. This way you'd service both cases, a new user would use the latest at that moment but on subsequent runs they'd be pinned. You can also ensure a seed.yml file is actually there in every case. Also just to follow up using node 16 in the build server did not cause any issues with me. Might make sense to just use that as the default now. AWS just added node 16 support on the 12th of last month, so I suspect several are moving to 16 to keep up. (I know you know about the recent change because sst scaffolds at 16.x, but in case anyone is reading and hadn't caught wind of that its big news!)

thank you both for replying to this thread, I absolutely appreciate the additional context and followup