From aad5614c0740a1006f65c3b71f1a6eaa49a25e3c Mon Sep 17 00:00:00 2001 From: Captain Turk Date: Thu, 23 May 2024 09:38:40 -0700 Subject: [PATCH] Update NPM_Security_Cheat_Sheet.md Minor typo fix for "along side". --- cheatsheets/NPM_Security_Cheat_Sheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cheatsheets/NPM_Security_Cheat_Sheet.md b/cheatsheets/NPM_Security_Cheat_Sheet.md index 0c6a2e52c4..e7a3ba2ab2 100644 --- a/cheatsheets/NPM_Security_Cheat_Sheet.md +++ b/cheatsheets/NPM_Security_Cheat_Sheet.md @@ -21,7 +21,7 @@ In January 2019, npm shared on their blog that they added a [mechanism that auto ## 2) Enforce the lockfile -We embraced the birth of package lockfiles with open arms, which introduced: deterministic installations across different environments, and enforced dependency expectations across team collaboration. Life is good! Or so I thought… what would have happened had I slipped a change into the project’s `package.json` file but had forgotten to commit the lockfile along side of it? +We embraced the birth of package lockfiles with open arms, which introduced: deterministic installations across different environments, and enforced dependency expectations across team collaboration. Life is good! Or so I thought… what would have happened had I slipped a change into the project’s `package.json` file but had forgotten to commit the lockfile alongside of it? Both Yarn, and npm act the same during dependency installation . When they detect an inconsistency between the project’s `package.json` and the lockfile, they compensate for such change based on the `package.json` manifest by installing different versions than those that were recorded in the lockfile.