Option to not install function node_modules on push

Describe the bug Amplify appears to be automatically installing function node_modules on push.

I have several Node.js lambda functions. I package the lambda entry point with required run-time dependencies as a pre-push step in order to reduce the published zip size. All of these dependencies are included under devDependencies instead of dependencies as they are not technically needed at run-time - they’ve been packaged up.

When I execute amplify push or amplify function push, I see all dependencies installed under each function shortly after executing the command. I imagine this was a decision made to ease deployment, but it creates issues in my situation where I consciously do not want the extra dependencies included in the Lambda zip, as I run into a Lambda size error (Unzipped size must be smaller than 262144000 bytes). If the extra install step is deliberate, is there a reason why it isn’t a production install, i.e. npm install --production, so that devDependencies are not installed?

Amplify CLI Version 4.23.0

To Reproduce

1. Create a Lambda function with a devDepenency
2. Execute amplify push
3. Observe that the devDependency has been installed within the function node_modules.

Expected behavior Amplify either does not automatically install node_modules, or makes the behavior configurable via a CLI argument.

Desktop (please complete the following information):

• OS: Debian 10
• Node Version. 12.13.1

Additional context I see there is an amplify function build that automatically installs function node_modules. Is this command getting run on push?

[kevcam4891]

After digging through cli versions, it appears the behavior changes 4.16 -> 4.17. The logic that determines whether installDependencies() gets called now checks to see if ANY file in the lambda directory is changes (stat.mtime > lastBuildTimeStamp). Before, it would just check the mtime for package.json.

I’m not sure what’s better: being able to keep a node_modules folder static between multiple pushes (nice during dev), or forcing an install at any possible sign of the directory being “stale” (better for prod). But I’d like to have the ability to not run installDependencies when pushing.

Anyone on the AWS side have any particular way to lean on a solution for this? Maybe amplify push --skip-install-pkg-deps?

[djsmedes]

We’ve worked around this by putting all our source files in a separate, sibling directory to src. We’ve named it pkg. Then adjusted our tsconfig.json settings such that the built js files get built into src. Then we copy over package.json, stripping out devDependencies with jq (which you have to install in your build script higher up with yum install jq). We also copy over yarn.lock for good measure. So we end up not needing to maintain multiple package.json files.

The final piece of the puzzle for us is a script in our package.json called “install for debug” that does the following:

yarn install --production --check-files --modules-folder=../src/node_modules && npm i --no-save --prefix ../ aws-sdk

This is run from pkg. It installs only the runtime dependencies into its sibling src/node_modules, then installs aws-sdk a level up, taking advantage of the node module resolution algorithm similar to your solution @javamonn. All this does is allow us to simulate the actual conditions of what packages will be available in the cloud when we’re running the lambda locally, so it’s not actually essential.

---

Despite @javamonn and I both finding functional workarounds, I don’t think this issue should be closed. I get why there’s an install step built into amplify push - you need your dependencies to be around so they can be zipped up into the deployment package - but it’s baffling that it doesn’t run in production mode and can’t even be configured to do so.

Given how often people customize their build settings, it would be nice to have the option to just turn off the install part of amplify push entirely. Include a console warning that says “You better know what you’re doing” if you use such an option if that makes it more likely to be implemented 🤷