That is strange, I'm not sure where the ws module ...
# help
t
That is strange, I'm not sure where the ws module is coming from I don't think we need that
Is there any default function props being set anywhere with ws as a nodeModule in the bundle
d
I mean I’m nearly 100% sure I’m looking at the correct function.
weird… looking at the package.json I see this…
why is it pushing a stub file when I’m providing a handler
t
Oh wait this was downloaded from AWS? This means the func is still in sst start mode
d
seems like it…. but I thought running
yarn deploy
flips it back to prod files?
t
Yeah it does. Are you sure it went to the right stage
d
dev stage all day for me
so yes?
t
I'm not sure, SST deploy definitely deploys your real code
Did you see the functions get updated?
d
working now… I think there was actually an error that I was not seeing
@thdxr hmmm… is there a trick to using
copyFiles
and the base handler? I can now see both files in the directory… but the lambda is erroring out with …
Copy code
{
    "errorType": "Runtime.HandlerNotFound",
    "errorMessage": "lib/constructs/ApiSite/lambda.handler is undefined or not exported",
    "stack": [
        "Runtime.HandlerNotFound: lib/constructs/ApiSite/lambda.handler is undefined or not exported",
t
Does that error go away when you remove the copyFiles field?
From what I'm seeing in that screenshot shouldn't be any issue, unless the handler isn't exported or something
d
checking…. this is my settings….
Copy code
const apiSite = new sst.Api(this, 'ApiSite', {
      defaultFunctionProps: {
        bundle: {
          copyFiles: [{ from: './contentful-app-frontend/build', to: './build' }],
        },
      },
      routes: {
        'ANY /': 'lib/constructs/ApiSite/lambda.handler',
        'ANY /{proxy+}': 'lib/constructs/ApiSite/lambda.handler',
      },
    })
still deploying…. but looking into the build folder I can see that by removing the copyFiles command the location of the handler changes back to the root.
seems like copyFiles may be F’n with the handler location somehow?
weird…. still getting
Copy code
{
  "errorType": "Runtime.HandlerNotFound",
  "errorMessage": "lib/constructs/ApiSite/lambda.handler is undefined or not exported",
  "stack": [
    "Runtime.HandlerNotFound: lib/constructs/ApiSite/lambda.handler is undefined or not exported",
    "    at Object.module.exports.load (/var/runtime/UserFunction.js:144:11)",
    "    at Object.<anonymous> (/var/runtime/index.js:43:30)",
    "    at Module._compile (internal/modules/cjs/loader.js:1072:14)",
    "    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)",
    "    at Module.load (internal/modules/cjs/loader.js:937:32)",
    "    at Function.Module._load (internal/modules/cjs/loader.js:778:12)",
    "    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:76:12)",
    "    at internal/main/run_main_module.js:17:47"
  ]
}
but the dir looks like ….
now I’m confused
t
let me try to recreate
d
hmmmm looking into the lambda code… it looks odd and I don’t see the handler
and that is the src handler
t
I think I can see the handler in the code - I definitely see a
/frontend
in the code
But maybe turn off minification and see
Do you know for sure that
export default { handler }
syntax works? I don't typically export that way
d
oh shit
missed that
no that looks wrong
sec
🤦‍♂️ hope that is it but also not…. cause that is embarrassing.
odd that linter didn’t catch that
def seeing some odd linting when functions are nested deeper than 1-2 directories in lib
t
It's technically valid, just when bundled by esbuild it interprets it differently
Copy code
const { handler } = require("./file")
vs
Copy code
import { handler } from "file"
Slight difference which causes it to fail depending on how
file
is bundled
d
I think that was it. No error this time