So my ultimate wish for

sst.Script

to help develop and debug scripts! (It's almost like a "deployment breakpoint") I found for simple cases, converting to a function is just fine. But for more complex cases, where you need the script to succeed for the rest of the deployment to work, then you get very stuck and resort to commenting out a lot of code everywhere to get the environment in a place where you can use the awesomeness of live lambda development. I'd love to be able to set a flag on a script that does the following on `sst start`: • The function is deployed in live mode • On deployment, when the script would normally be executed (by create or update), the deployment halts there! (Breakpoint) • In "interactive mode", the function becomes live for local development immediately. You can invoke the lambda, change the code, do whatever you like (just like function live development) • It gives you helpers, eg. print out an AWS CLI command to invoke the lambda the same way that it would be by cloud formation. Or some kind of console. So by default you can just execute it exactly as it normally would be done with the same params as in the stack code. • You can at any point continue with deployment or rollback, (marking it as success or failed), and cloud formation continues appropriately It would make working with scripts an absolute delight 🙂

For similar issue in my app, I've decided to add an admin endpoint protected with IAM credentials. I'm calling it with 'awscurl' binary. Scripts triggers regular lambda migrations or step functions for long running one. Migration state is saved in dynamodb (fail, success, migration history) . Admin endpoint can trigger same code as a sst Script. Live reload + debugger works like in regular sst start scenario.

So you always deploy your scripts as functions? Then just use scripts to trigger the functions?. The only problem I found was that calling live functions from scripts during deployment doesn't work because the live dev environment only fires up after everything is deployed, not during deployment.

Lambda for sst Script and lambda for REST admin endpoint shares the same code. During development I use ''sst start' and call my REST admin endpoint to test particular migration/all migrations. Here live reload works like in regular REST api development case. On deployment time, assuming I tested all correctly 🙂 it should just read previous version and apply pending migrations.

Interesting... I think that would work for most cases I can think of. The times it wouldn't quite work are when a script needs to run during the deployment and cannot be run afterwards. That doesn't seem to happen too often though. So your flow would be to develop a script as a function first, get it working right, then add it as a script?

yes, most of the time

Nice, thanks for this insight

Interesting insights guys @Ryan @Slawomir Stec

Exactly @Frank. You said it so much clearer than I did.