sst: [RFC] Hot reload (Live Lambda Development) doesn't work if function is not in subfolder

Description

SST only watches for functions that are located in one of the subfolders of an SST project. As consequence, it makes it hard to be integrated into an already existing monorepo.

For instance, SST does not allow for hot reloading in a project that has this structure:

.
├── deployment/                 <-- The SST project
    ├── stacks/
    │   ...
    └── sst.config.ts
└── functions/                  <-- The folder with the lambda projects
    ├── lambda1/
    │   ├── index.ts
    │   └── package.json
    ├── lambda2/
    │   ├── index.ts
    │   └── package.json

Reproduction

  1. Run the cmds below
$ cd /tmp
$ npm init sst
$ mv my-sst-app/packages packages
$ (cd packages/core ; npm i)
$ (cd packages/functions ; npm i)
$ cd my-sst-app ; npm install ; npm run dev
  1. Replace "./packages/functions/src/lambda.handler" by "../packages/functions/src/lambda.handler" at my-sst-app/stacks/MyStack.ts:6
  2. Edit the functions code (e.g. add console.log('hello') inside /tmp/packages/functions/src/lambda.ts) and observe the results. Only the first run will be correct, while no subsequent invocations will have the code updated.

Notes

  • I have tried it out on SST versions 2.1.12, and 2.1.4
  • I tried symlinking the functions folder inside the SST project, but it didn’t help

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 6
  • Comments: 19 (16 by maintainers)

Most upvoted comments

Yup replied

Oh that’s interesting. Thanks for sharing.

what stops you from moving only the sst.config.js one level up and update the imports accordingly?

This is what I’ve ended up doing. I actually have an sstConfig.ts within the infra project, and the sst.config.ts used by the binary in the parent dir simply imports/exports the content of sstConfig.ts.

This works fine, but relies on the sst binary being available at the correct version outside of any npm project directory.

Okay, I have looked deeper into SST’s code and there are a few assumptions I think I can make from my findings:

A. There is a centralised watcher which is being called in 2 different places. The logic couldn’t be simpler (👏): https://github.com/serverless-stack/sst/blob/186b545b3795f6a285534ff05d196ab8a04e3daa/packages/sst/src/watcher.ts#L20-L23 B. Not allowing for symlinks as well as watching only the insides of the SST project seem to be “by design / intentional”. C. There is currently no workaround possible for the issue being reported.

Thus, it seems safe to conclude that SST is not friendly with monorepos structured differently than in the only way accepted by SST (which is the case for pretty much any pre-existing project 🤷‍♀️).