Using esbuild with a monorepo and a shared folder at the root

[r-token]

We use a monorepo for our serverless projects, and its basic structure looks like this:

├── services
│    └── service-one
│        ├── handler.js
│        ├── package.json
│        ├── README.md
│        └── serverless.yml
│
│    └── service-two
│        ├── handler.js
│        ├── package.json
│        ├── README.md
│        └── serverless.yml
│
├── shared   // shared code used in multiple services
│    └── commonUtils.js
│
├── package.json
├── README.md
├── serverless-compose.yml
└── .gitignore

Make note of the shared folder at the root of the repo.

Within each service's handler function, we often reach into the shared/commonUtils.js file at the root. This is packaged up in each service's serverless.yml file with the correct path (../../shared/commonUtils.js), but within the handler.js function itself, it's referenced as ./shared/commonUtils.js since the shared folder and the handler function are at the same level once packaged up and deployed as a lambda function.

Since the ./shared/commonUtils.js path locally is not correct, esbuild complains and says it cannot resolve that file. Which makes sense, but is there a way for me to get around this?

[samchungy]

The easiest way is to just let esbuild resolve the shared folder (eg. ../../shared/commonUtils.js and to not use the Serverless package patterns? Doesn't your IDE complain that it cannot find the path too? You could possibly make use of tsconfig.json paths if you're using typescript

[r-token]

The answer ended up being essentially that, yes. I got rid of all my custom package.patterns for each function and only kept the baseline package block at the service level, with only the individually: true option set.

After I removed my custom patterns, I was able to specify the actual ../../shared/commonUtils path in the handler functions so esbuild was able to see them. esbuild was able to take it from there and bundle everything up successfully.

Thanks for the input!