Using a freshly scaffolded SST app with seed I get...
# seed
Using a freshly scaffolded SST app with seed I get
Copy code
error constructs@10.1.31: The engine "node" is incompatible with this module. Expected version ">= 14.17.0". Got "14.15.4" error Found incompatible module.
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 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
Copy code
  - 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
Yeah, I typically set this to the same version as the lambda runtime for consistency. (currently 16.14.0)
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.
@Jesse Harlin good point. Initially we didn’t want to update the minor versions of runtimes to ensure ppl’s build don’t break on version updates.
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.
@Ross Coundon in the documentation it stated that 14.x was the highest supported version so I haven't tried v16. I figured that wouldn't matter since this is just the build container, but like you it really does kind of lower the cognitive overhead if everything is the same for me
@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 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