Current Behavior
Code changes in handlers take effect only after serverless server restart. I updated to current [email protected] and [email protected] version in order to support WebSockets and the live-update feature stopped working. No configuration changes were made. On a previous version [email protected] and [email protected] it worked fine.
Expected behavior/code
After changes in handlers, subsequent API requests will invoke current code but not the one which was on startup of the serverless server.
Environment
serverless version: 1.58.0serverless-offline version: 6.0.0-alpha.48node.js version: v10.16.2OS: macOS 10.15.1hey @MEGApixel23 thank you for opening this bug report.
the reloading functionality has been removed for the time being, as it caused quite a bit of confusion, as the user had to explicitly opt out if the reloading functionality was not desired. in addition, it was the cause of several memory leaks, as the handler process runs in the same process as serverless and this plugin.
I still have some sort of reloading functionality on my to-do-list (either as it was before, reload on every request, or only reload when a file actually was changed (watch files). either way, it will be an opt-in as opposed to an opt-out. the memory leaks also should be taken care of with the introduction of worker threads support running the handlers.
in the meanwhile you can use tools like nodemon, example here: https://github.com/dherault/serverless-offline/tree/master/examples/tools/nodemon
@dnalborczyk thanks for the example. Have you ever tried using nodemon with typescript? Seems I can't get out of loop of nodemon finding changes and restarting all the time with:
nodemon --watch .build --exec serverless offline -e js,yml
Not sure this is worth closing鈥β爄t seems like a major fault of the offline emulation, given this is designed for development. Having to restart the offline server with each file change is quite slow. I do understand that sometimes it could lead to memory leaks, and I can understand it being an opt-in feature, however, this was pre-existing functionality so removing it is a breaking change. It has made updating to the new version of serverless-offline difficult. Completely breaks development using websockets, since now the websockets are disconnected on restart. I don't really want to write a ton of logic for attempting to reconnect to the websocket server upon disconnect from the clients, since in a production environment that code could cause problems.
@dnalborczyk what needs to get implemented in serverless-offline for this feature to be re-added? It may be quicker for me to contribute a pull request here, if that is possible.
any updates here?
Most helpful comment
Not sure this is worth closing鈥β爄t seems like a major fault of the offline emulation, given this is designed for development. Having to restart the offline server with each file change is quite slow. I do understand that sometimes it could lead to memory leaks, and I can understand it being an opt-in feature, however, this was pre-existing functionality so removing it is a breaking change. It has made updating to the new version of
serverless-offlinedifficult. Completely breaks development using websockets, since now the websockets are disconnected on restart. I don't really want to write a ton of logic for attempting to reconnect to the websocket server upon disconnect from the clients, since in a production environment that code could cause problems.@dnalborczyk what needs to get implemented in
serverless-offlinefor this feature to be re-added? It may be quicker for me to contribute a pull request here, if that is possible.