Invoke locally and symbolic links do not play nicely

I have a project where I am including some common code into several services. The structure looks something like this:

common-code

service1
– ln-s …/common-code .

service2
– ln-s …/common-code .

When I deploy, serverless copies the files from the linked common-code folder into the build and everything works as expected.

However, when I try to runt he function locally, I get a module not found error.

If I remove the link and simply copy the common-code folder then it works. So it is clear that the function is ok, and runs locally as expected, but serverless is ignoring the linked code when it does so.

Obviously I wish to maintain the link rather than duplicate code. I’d also rather not have to delete the link and copy the code, test, then delete the code and replace the link each time I want to test locally.

Is this a bug? A known limitation?

Does anyone have a work around for this?

2 Likes

Did you find a workaround or convenient solution for this?

Sorry for the late reply - didn’t notice your question.

Yes. I have a work around. You have to create a package.json in the common folder and run npm i to install any libraries.

It seems the when you run locally, any files in that common folder expect to find their node-modules in that common folder, But when you deploy, it takes them from the main folder.

Whilst seemingly a pain in the neck, this does have one handy benefit for me. I am using Camaro which required me to have one compiled binary when running locally and a completely different one deployed to AWS.

So I have the Mac binary installed in common and AWS binary in my main folder. I then removed all Camaro calls from doe in my main folder and put a very simple wrapper function in common.

So, when I run locally, that call expects to find camaro in my common folder and thus it picks up the Mac binary. But when I deploy, it deploys the AWS binary from my main folder.