Hi all, I am getting the following error message:...
# help
Hi all, I am getting the following error message:
Copy code
Preparing your SST app
Detected tsconfig.json
Transpiling source
There was a problem transpiling the source.
It appears this is caused by the following error handling in the SST code:
Copy code
try {
    const result = await esbuild.build(esbuildOptions);
    require('fs').writeFileSync(metafile, JSON.stringify(result.metafile))
  } catch (e) {
    // Not printing to screen because we are letting esbuild print
    // the error directly
    throw new Error("There was a problem transpiling the source.");
Anyone got any ideas as to why this is happening? I am trying to start SST from inside a docker container.
If you run the same thing outside of a docker container, do you get the same problem?
@Ross Coundon It works outside the container without any issues
For docker, I run it as follows:
ENVIRONMENT_NAME=Integration docker-compose run sst_integration npx sst  start  -- --stage Integration
The error that is thrown in the SST code is the following:
Error: spawn Unknown system error -8
Changed the version of the docker image to not be
, that has now changed the error to the following:
Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
Think I figured it out, I think it has to do with how I was bind mounting a volume in docker. Seems to work ok now
Nice! Btw @Fazi, I’m curious why you are running SST inside docker?
Hi @Frank, the reason is mostly because I am using Python lambda functions, which need a couple of libraries installed to run in the local environment. I initially used virtual environments, but found that docker was a bit easier to manage with other devs (i.e. no need to get other developers to download poetry or pyenv etc as docker was already available).
I will probably revisit this a bit later and see if I can find a better way of doing things
Ah I see. For
sst start
, I was thinking to support building and running Python functions inside docker. But ur setup also works! I think urs might even be faster b/c SST doesn’t have to start/stop a docker contain to handle each request.
Lemme just cc the team (@Jay @thdxr) so they are aware of this approach.
thanks @Frank
Ah smart running everything inside docker
Hey @Fazi, any chance you can share your Dockerfile? I'm trying to do the same thing for my current work and I'm fairly new to Docker. I'm certain I'm making awful mistakes in my current setup
Hi @Seth Geoghegan, I actually couldn't get it to work inside Docker - I think the issue was it was launching a docker container inside a docker container (kinda like that Inception film), and this caused the inner Docker container to not know how to communicate with the outside world. Fixing it seemed a bit too fiddly (I was also using Docker relatively newly). Instead what I did was to use Poetry https://python-poetry.org/. I stuck the Poetry.toml file in the root of my project (thus every subfolder, such as test, sourcePath, utilities etc had access to the poetry environment). As I was using Python for lambda functions, I simply output a requirements.txt file from poetry into my source path. This for me worked very well with serverless and made writing Lambda functions a breeze. Here is what my docker file looked like at the time nonetheless:
Copy code
version: "3.9"
        image: 'sst-integration'
        container_name: 'sst-integration'
        build: ./sst_integration
            - "8040:8040"
            - ./sst_integration:/src/sst_integration
            - /src/sst_integration/node_modules
            - ~/.aws/:/root/.aws:ro
        stdin_open: true
        tty: true
            - sandbox
        name: sandbox_network
I am sure there are much better ways to get it all working though.
ps. If you do manage to figure out how to get Docker to work correctly please do give a shout - I am curious myself and will likely revisit it when I have more downtime.
Thanks for this! I have gotten it working, but it's awfully slow. I think it has more to do with my dev environment (mac+docker and volumes/mounts) than SST.
the 'yarn install' step takes many times longer than running locally (20-ish seconds on the host vs 3+ minutes in the container), which I believe is a documented issue with the yarn+docker combo
I'm with you though, the local setup is so smooth, I'm gonna punt on the docker version for now. I'll probably need to get it working at some point, since I have a team of 40+ engineers that will need to run this service, and I don't want to require everyone to have the same python/npm setup locally
@Seth Geoghegan Great, glad to hear it is working for you!