Cannot use 3d party libraries

[purefan]

Hello,

I am unable to run a local lambda that relies on third party libraries, for example the redis one. The error I get is:

Unable to import module 'index'

For troubleshooting I:

• Started sam local with debug enabled (sam local start-api--template notification.sam.yml --debug-port 5858)
• Sent a curl request
• Attached VSCode debugger which was probably not needed.
• Found the docker container that spawned (docker ps and there was only one)
• Attached an interactive shell to that container (docker exec -it <machine_alias> bash)
• And tried to find the node_modules for my lambda, it wasn't in the execution folder (where my index.js was) and couldn't find it anywhere else.

I also tried with the static-dir flag (sam local start-api--template notification.sam.yml --debug-port 5858 --static-dir node_modules) but didn't see any difference.

I think sam local takes all *.js files in the lambda root but ignores the package.json file and the node_modules folder. Can someone please let me know if Im doing something wrong or if this perhaps is expected behavior?

[sanathkr]

Where is your node_modules with respect to the CodeUri?

Usually, if CodeUri points to a directory that contains your node_modules, it gets directly mounted in the Docker container. But if you don't have that structure, then you need some build process (gulp?) that moves code around in right structure for you. This is required anyway because Lambda cloud will expect the same structure as SAM Local.

[hugobast]

@sanathkr I want to corroborate what @purefan said, if you have node_modules and bash into the docker instance you will find all the files under the folder that CodeUri is pointing to minus node_modules and package.json

[danielwhatmuff]

Ran into this same issue with python. Can sam local just expect a requirements.txt / package.json file by convention and do the logic to download that package to a local destination where it needs to be?

[heitorlessa]

Daniel, take a quick look here: https://github.com/heitorlessa/sam-local-python-hot-reloading I haven't finished the README to give more details as to why this works but looking at the Makefile will give you the answer. I use this to provide hot-reloading for Python when developing using SAM Local and all I have is my source code folder and a requirements (sometimes private packages too).

…

On Wed, 14 Feb 2018 at 11:02 Daniel Whatmuff ***@***.***> wrote: Ran into this same issue with python. Can sam local just expect a requirements.txt / package.json file by convention and do the logic to download that package to a local destination where it needs to be? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADL4BH6y1OzUf03JVMEz_Xm0lyqI3XbYks5tUr0sgaJpZM4Pavtc> .

[ffxsam]

No disrespect to the AWS SAM team, but I’d recommend checking out serverless.com. It’s an open source wrapper around serverless platforms (including AWS), and it makes it incredibly easy to test Lambda functions and API Gateway endpoints. It has no issues with third party libraries. It actually uses webpack to bundle your code, so you can even use ES6 and TypeScript if you’d like.

[ffxsam]

@purefan I noticed you thumbs-downed my suggestion. I'm curious as to why. When tools get in the way of getting things done, IMO it makes more sense to find another tool. It's now May, and nobody else has offered up a solution to this issue yet.

[alukach]

@purefan I've had success using rollup to transpile my scripts from TypeScript to CommonJS. This includes third-party modules.

I can provide more information if needed. To be honest, I'm pretty green to Rollup and Typescript so maybe this is obvious to others.

@danielwhatmuff 👍 torequirements.txt / package.json. My current workaround is to place the Lambda files among the Python dependencies and make CodeUri point there:

CodeUri: "venv3.5/lib/python3.5/site-packages"

Yeah, not ideal.

[alukach]

For the TypeScript crowd, I created a quick boilerplate to help get a SAM project (w/ 3rd party lib support) spun up quickly: https://github.com/alukach/aws-sam-typescript-boilerplate It should be pretty simple to refactor for vanilla JavaScript support.

I also had a Python example working but it was pretty ugly as it relied on zipping up all the dependencies and sending those to the the lambda. @claudiobizzotto's suggesting sounds slightly better, but still not great.