CI installs different transitive dependency versions than developers' laptops, and Elastic Beanstalk deploys then fail. What practice prevents that drift?
Select an answer to reveal the explanation.
Short Explanation
If CI and your laptop disagree on library versions, Beanstalk will referee—and citizens lose. Commit the lockfile and make CI install from it so the artifact matches what you tested. Floating ranges are how municipal builds go mysterious.
Full Explanation
CI that installs different transitive dependency versions than developer laptops causes Elastic Beanstalk deploys to fail when the resolved graph drifts. Committing and honoring lockfiles so CI and deploy builds resolve the same dependency graph every time prevents that municipal packaging drift. Lockfiles are the contract between local development and the pipeline artifact, and Domain 3 expects that contract to be versioned and enforced—not optional documentation.
Allowing CI to use npm install without a lockfile so ranges always float to newest fails because newest is not the tested dependency set and can break overnight. Pinning nothing and rebuilding locally only when production breaks fails conceptually—it discovers drift too late for citizens already hitting errors. Vendoring random copies of node_modules from different engineers into the Beanstalk bundle fails by importing inconsistent trees without a single source of truth.
Exam caveat: regenerating a lockfile locally on a different OS without CI verification can still introduce surprises; treat lockfile changes as reviewable diffs in the municipal repo. Operational check: compare CI install logs to the lockfile, fail builds on lockfile out-of-sync conditions, and redeploy Beanstalk from the CI-built bundle only.