Developers commit compiled node_modules into Git so municipal deploys feel reproducible, but diffs are noisy and CI still sees platform skew. What is the better approach?
Select an answer to reveal the explanation.
Short Explanation
Your laptop folder is not the release train. Lock the dependency graph, then let CI assemble a clean artifact so Beanstalk or Lambda gets what was tested—not whatever was last npm-installed on someone's Mac. Checking in node_modules just papers over the real build.
Full Explanation
Separating build from deploy means CI produces artifacts from declared dependencies using committed lockfiles rather than uploading developer working trees. Committing lockfiles and building clean deployable artifacts in CI prevents noisy node_modules diffs and reduces OS/CPU binary skew for municipal Elastic Beanstalk or Lambda Node services. Workstation folders are not the artifact; reproducible installs from the lockfile are the DVA packaging practice that keeps city deploys honest across laptops and builders.
Continuing to commit node_modules and disabling CI installs to trust each laptop fails because laptop binaries and transitive trees still drift across platforms and architectures. Deleting package-lock.json so every environment resolves floating ranges freely fails conceptually by maximizing version skew between developers, CI, and Beanstalk. FTP of node_modules from a developer desktop directly into the Elastic Beanstalk environment fails as an uncontrolled, non-auditable deploy path that bypasses CI evidence.
Exam caveat: lockfiles must be honored by the same package manager version family CI uses; ignoring peer dependency changes can still break builds even with a lockfile present. Operational check: wipe local node_modules, run a clean CI-equivalent install from the lockfile, deploy that artifact only, and confirm platform-native modules match the Beanstalk or Lambda architecture.