{"id":454,"date":"2026-01-26T06:41:47","date_gmt":"2026-01-26T06:41:47","guid":{"rendered":"https:\/\/codebounce.debojyotichatterjee.com\/?p=454"},"modified":"2026-01-26T06:41:47","modified_gmt":"2026-01-26T06:41:47","slug":"understanding-package-json-and-package-lock-json","status":"publish","type":"post","link":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/2026\/01\/26\/understanding-package-json-and-package-lock-json\/","title":{"rendered":"Understanding package.json and package-lock.json"},"content":{"rendered":"\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"560\" src=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/unnamed-2-1024x560.png\" alt=\"\" class=\"wp-image-467\" srcset=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/unnamed-2-1024x560.png 1024w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/unnamed-2-300x164.png 300w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/unnamed-2-768x420.png 768w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/unnamed-2-1536x839.png 1536w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/unnamed-2-2048x1119.png 2048w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>When you are building on any JavaScript application (for example&nbsp;<strong>Node.js or ReactJS)<\/strong>, you quickly discover two files&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;and&nbsp;<strong><code>package-lock.json<\/code>.<\/strong>&nbsp;These two files are very important and form the backbone of dependency management in your project to ensure your project runs smoothly whether you&#8217;re developing locally or deploying to a server.<\/p>\n\n\n\n<p>Think of&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;as your project&#8217;s&nbsp;<strong>identity.<\/strong>&nbsp;This file contains essential information about your application, like its name, version, description, and most importantly, the list of dependencies that your project needs to function.<\/p>\n\n\n\n<p>And,&nbsp;<strong><code>package-lock.json<\/code><\/strong>&nbsp;acts as a&nbsp;<strong>lock<\/strong>(as the name suggests)\u2014it locks down the exact versions of all your dependencies to ensure everyone working on your project on their individual machines use precisely the same versions.<\/p>\n\n\n\n<p>These two files ensure consistency across your entire team and deployment pipeline.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"557\" src=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/dependency_tree-1024x557.png\" alt=\"The complaxity of a dependency tree.\" class=\"wp-image-459\" srcset=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/dependency_tree-1024x557.png 1024w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/dependency_tree-300x163.png 300w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/dependency_tree-768x417.png 768w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/dependency_tree-1536x835.png 1536w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/dependency_tree-2048x1113.png 2048w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Understanding the Manifest File<\/h2>\n\n\n\n<p>The&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;file is the&nbsp;<strong>manifest file<\/strong>&nbsp;of your Node.js project. It&#8217;s a simple JSON file that sits in the root directory of your project and contains metadata about your application along with a list of dependencies your project requires to function.<\/p>\n\n\n\n<p>Every Node.js project should have a&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;file. When you initialize a new Node.js project, npm (Node Package Manager) helps you create this file with basic information like your project name, version number, and a description of what your project does.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Key Fields in package.json<\/h2>\n\n\n\n<p>Here are the most important and primary fields that you will see in a typical&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;file:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Name<\/strong>: The name of your project.\u00a0<em>(This field is required if you plan to publish your package to npm.)<\/em><\/li>\n\n\n\n<li><strong>Version<\/strong>: The current version of your project (e.g.,\u00a0<strong><code>1.0.0<\/code><\/strong>).<\/li>\n\n\n\n<li><strong>Description<\/strong>: A brief explanation of what your project does, helping others understand its purpose. This is usually optional.<\/li>\n\n\n\n<li><strong>Main<\/strong>: The entry point of your application. This file is the primary file that executes first when you need to run your project or if it\u2019s a package it is loaded when someone imports your package using\u00a0<code>require()<\/code>\u00a0or\u00a0<code>import<\/code>.<\/li>\n\n\n\n<li><strong>Scripts<\/strong>: Custom commands you can run with\u00a0<code>npm<\/code>\u00a0or any other package manager like\u00a0<code>yarn<\/code>\u00a0or\u00a0<code>pnpm<\/code>. These might include\u00a0<strong><code>start<\/code><\/strong>\u00a0to run your app,\u00a0<strong><code>test<\/code><\/strong>\u00a0to run tests, or\u00a0<strong><code>build<\/code><\/strong>\u00a0to prepare your project for production.<\/li>\n\n\n\n<li><strong>Dependencies<\/strong>: Packages your application needs to run. These are installed in production environment.<\/li>\n\n\n\n<li><strong>DevDependencies<\/strong>: Packages needed only during development, like testing frameworks or build tools. These are not installed in production.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Creating Your First package.json<\/h2>\n\n\n\n<p>Creating a&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;file is straightforward. Navigate to your project directory and run:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm init<\/code><\/pre>\n\n\n\n<p>This command launches an interactive prompt where you provide information about your project. If you want to skip all prompts and use defaults, use:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm init -y<\/code><\/pre>\n\n\n\n<p>After running this command, you&#8217;ll have a basic&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;file ready to customize. Here&#8217;s what a simple&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;looks like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"name\": \"my-awesome-app\",\n  \"version\": \"1.0.0\",\n  \"description\": \"A simple Node.js application\",\n  \"main\": \"server.js\",\n  \"scripts\": {\n    \"start\": \"node server.js\",\n    \"dev\": \"nodemon server.js\",\n    \"test\": \"jest\"\n  },\n  \"keywords\": &#91;\"nodejs\", \"javascript\", \"web-app\"],\n  \"author\": \"Your Name\",\n  \"license\": \"MIT\",\n  \"dependencies\": {\n    \"express\": \"^4.18.2\",\n    \"dotenv\": \"^16.0.3\"\n  },\n  \"devDependencies\": {\n    \"nodemon\": \"^2.0.20\",\n    \"jest\": \"^29.0.0\"\n  }\n}<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Installing and Managing Dependencies<\/h2>\n\n\n\n<p>To add a new package to your project, you use the&nbsp;<strong><code>npm install<\/code><\/strong>&nbsp;command. For example, to add the&nbsp;<strong>Express<\/strong>&nbsp;web framework:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install express<\/code><\/pre>\n\n\n\n<p>This command downloads the package from the npm registry and adds it to your&nbsp;**<code>dependencies<\/code>**in&nbsp;<strong><code>package.json<\/code><\/strong>.<\/p>\n\n\n\n<p>Additionally you will also find a new folder added to your&nbsp;<code>node_modules<\/code>&nbsp;folder which contains all the files related to the dependency you just installed.<\/p>\n\n\n\n<p>If you want to add a development-only dependency (like a testing framework or a logger):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install --save-dev loggernaut<\/code><\/pre>\n\n\n\n<p>To remove a dependency:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm uninstall lodash<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">What is package-lock.json?<\/h2>\n\n\n\n<h2 class=\"wp-block-heading\">The Lock File Explained<\/h2>\n\n\n\n<p>The&nbsp;<strong><code>package-lock.json<\/code><\/strong>&nbsp;file will get&nbsp;<strong>automatically generated\/updated<\/strong>&nbsp;whenever npm modifies the&nbsp;<strong><code>node_modules<\/code><\/strong>&nbsp;folder or the&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;file. Its primary purpose is to&nbsp;<strong>freeze down the exact versions<\/strong>&nbsp;of all dependencies in your project.<\/p>\n\n\n\n<p>In&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;version ranges have symbols like&nbsp;<strong><code>^<\/code><\/strong>&nbsp;and&nbsp;<strong><code>~<\/code><\/strong>&nbsp;which allows a certain extent of flexibility and the&nbsp;<strong><code>package-lock.json<\/code><\/strong>&nbsp;file records the&nbsp;<strong>exact versions<\/strong>&nbsp;that were installed when the&nbsp;<code>npm install<\/code>&nbsp;command is run. This ensures that every developer on your team, and every deployment environment, uses the&nbsp;<strong>same exact versions<\/strong>&nbsp;of dependencies provided they have the same&nbsp;<strong><code>pakage-lock.json<\/code><\/strong>&nbsp;file.&nbsp;<strong>This is why it\u2019s a good idea to push the&nbsp;<code>package-lock.json<\/code>&nbsp;file in your git repository.<\/strong><\/p>\n\n\n\n<p>This file is crucial for consistency and reproducibility. Without it, different machines might install slightly different versions of packages (especially patch versions), leading to unexpected bugs or missing an unexpected bugs that may be happening in production.&nbsp;<em><strong>This is what prevents the classic problem of &#8220;it works on my machine but not in production!&#8221; from arising.<\/strong><\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Structure of package-lock.json<\/h2>\n\n\n\n<p>A&nbsp;<strong><code>package-lock.json<\/code><\/strong>&nbsp;file contains detailed information about your entire dependency tree. Here&#8217;s a simplified example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"name\": \"my-awesome-app\",\n  \"version\": \"1.0.0\",\n  \"lockfileVersion\": 2,\n  \"requires\": true,\n  \"packages\": {\n    \"\": {\n      \"name\": \"my-awesome-app\",\n      \"version\": \"1.0.0\",\n      \"dependencies\": {\n        \"express\": \"4.18.2\"\n      }\n    },\n    \"node_modules\/express\": {\n      \"version\": \"4.18.2\",\n      \"resolved\": \"&lt;https:\/\/registry.npmjs.org\/express\/-\/express-4.18.2.tgz>\",\n      \"integrity\": \"sha512-...\",\n      \"dependencies\": {\n        \"body-parser\": \"1.20.1\",\n        \"cookie\": \"0.4.2\"\n      }\n    }\n  }\n}<\/code><\/pre>\n\n\n\n<p>Here are the most important and primary fields that you will see in a typical&nbsp;<strong><code>package-lock.json<\/code><\/strong>&nbsp;file:<\/p>\n\n\n\n<p><strong>lockfileVersion<\/strong>: Indicates which version of the lock file format is being used. Different&nbsp;<code>npm<\/code>&nbsp;versions use different formats (version 1, 2, or 3).<\/p>\n\n\n\n<p><strong>requires<\/strong>: A boolean flag indicating whether to read and use the dependency tree.<\/p>\n\n\n\n<p><strong>packages<\/strong>: Contains information about each package in your project dependency tree, including the exact version, download URL, integrity hash, and sub-dependencies.<\/p>\n\n\n\n<p><strong>dependencies<\/strong>: Legacy field that lists direct dependencies and their versions for backward compatibility.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Why package-lock.json is Important<\/h2>\n\n\n\n<p><strong>Dependency Reproducibility<\/strong>: Makes sure your project uses exact dependency versions, so you always have the same setup, wherever and whenever you install. This ensures you won\u2019t face unexpected changes or surprises.<\/p>\n\n\n\n<p><strong>Prevents Unexpected Breaking Changes<\/strong>: Lock files also protect you from sudden breaking changes. If you don\u2019t use them, you might get new updates\u2014even bug fixes or minor changes\u2014that could unexpectedly break your code. With a lock file, you have a safety net.<\/p>\n\n\n\n<p><strong>Team Collaboration<\/strong>: Collaborating in a team becomes much simpler, too. Everyone gets the same versions, so you don\u2019t spend hours tracking down differences or asking,&nbsp;<em>\u201cwhy does it work for you but not for me?\u201d<\/em><\/p>\n\n\n\n<p><strong>Continuous Integration (CI) Benefits<\/strong>: In continuous integration pipelines, lock files ensure every build is identical. You always know what\u2019s being deployed to production, every time.<\/p>\n\n\n\n<p><strong>Faster Installations<\/strong>: npm can skip version resolution steps since exact versions are already specified.&nbsp;<code>npm<\/code>&nbsp;already knows which versions to install, skipping the extra step of figuring out what\u2019s compatible. That means less waiting and more time coding<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">package.json vs package-lock.json: Key Differences<\/h2>\n\n\n\n<p>Here&#8217;s a comprehensive comparison for the above explanation:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"577\" src=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/comparison-1024x577.png\" alt=\"package.json vs package-lock.json: Key Differences\" class=\"wp-image-460\" srcset=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/comparison-1024x577.png 1024w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/comparison-300x169.png 300w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/comparison-768x433.png 768w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/comparison-1536x865.png 1536w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/comparison-2048x1154.png 2048w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/comparison-1280x720.png 1280w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th><strong>Feature<\/strong><\/th><th><strong>package.json<\/strong><\/th><th><strong>package-lock.json<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong>Purpose<\/strong><\/td><td>Defines project metadata and dependencies.<\/td><td>Locks exact versions of dependencies.<\/td><\/tr><tr><td><strong>Version Specification<\/strong><\/td><td>Uses version ranges (^1.2.3, ~1.2.3).<\/td><td>Records exact locked versions (1.2.3).<\/td><\/tr><tr><td><strong>Manual Editing<\/strong><\/td><td>Developers edit directly.<\/td><td>Automatically generated and updated.<\/td><\/tr><tr><td><strong>Flexibility<\/strong><\/td><td>Allows version flexibility for updates.<\/td><td>Zero flexibility\u2014exact versions only.<\/td><\/tr><tr><td><strong>File Size<\/strong><\/td><td>Small and human-readable.<\/td><td>Large (includes entire dependency tree).<\/td><\/tr><tr><td><strong>Version Control<\/strong><\/td><td>Should be committed.<\/td><td>Should be committed.<\/td><\/tr><tr><td><strong>Primary Audience<\/strong><\/td><td>Developers.<\/td><td>npm and CI\/CD systems.<\/td><\/tr><tr><td><strong>Lock Guarantee<\/strong><\/td><td>Partial (only direct dependencies).<\/td><td>Complete (entire dependency tree).<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Semantic Versioning: Caret (^) and Tilde (~)<\/h2>\n\n\n\n<h2 class=\"wp-block-heading\">Understanding Version Ranges<\/h2>\n\n\n\n<p>One of the most important thing in package management is&nbsp;to understand&nbsp;<strong>semantic versioning<\/strong>&nbsp;(often called &#8220;semver&#8221;). This system uses three numbers in the format&nbsp;<strong><code>MAJOR.MINOR.PATCH<\/code><\/strong>&nbsp;(e.g.,&nbsp;<strong><code>4.18.2<\/code><\/strong>), where:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MAJOR<\/strong>\u00a0version increases when you make incompatible, breaking changes in accordance with the previous versions.<\/li>\n\n\n\n<li><strong>MINOR<\/strong>\u00a0version increases when you add new features that are backward compatible.<\/li>\n\n\n\n<li><strong>PATCH<\/strong>\u00a0version increases when you fix bugs in a backward compatible manner.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"556\" src=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_ranges-1024x556.png\" alt=\"Understanding Version Ranges\" class=\"wp-image-461\" srcset=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_ranges-1024x556.png 1024w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_ranges-300x163.png 300w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_ranges-768x417.png 768w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_ranges-1536x833.png 1536w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_ranges-2048x1111.png 2048w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>In your&nbsp;<strong><code>package.json<\/code><\/strong>, you may see two symbols before version numbers: the&nbsp;<strong>caret (^)<\/strong>&nbsp;and the&nbsp;<strong>tilde (~)<\/strong>. These symbols instruct the package manager&nbsp;<code>npm<\/code>&nbsp;which types of updates are safe to install.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"549\" src=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_notaions-1024x549.png\" alt=\"Understanding Version Ranges\" class=\"wp-image-462\" srcset=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_notaions-1024x549.png 1024w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_notaions-300x161.png 300w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_notaions-768x412.png 768w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_notaions-1536x823.png 1536w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/version_notaions-2048x1098.png 2048w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Tilde (~): Patch Version Updates<\/h3>\n\n\n\n<p>The tilde symbol instructs&nbsp;<code>npm<\/code>&nbsp;to install only&nbsp;<strong>patch versions<\/strong>. This is the most conservative and safe approach.<\/p>\n\n\n\n<p>If you have mentioned&nbsp;<strong><code>\"express\": \"~4.18.2\"<\/code><\/strong>, in the absence of&nbsp;<code>package-lock.json<\/code>&nbsp;file&nbsp;<code>npm<\/code>&nbsp;can install any patch version of&nbsp;<code>4.18.x<\/code>, such as&nbsp;<code>4.18.3<\/code>,&nbsp;<code>4.18.4<\/code>, or&nbsp;<code>4.18.5<\/code>.<\/p>\n\n\n\n<p>It will&nbsp;<strong>NOT<\/strong>&nbsp;install&nbsp;<code>4.19.0<\/code>&nbsp;or any&nbsp;<code>5.x<\/code>&nbsp;version.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>text~4.18.2  \u2192  Allows: 4.18.2, 4.18.3, 4.18.4, 4.18.5...\n\t\tBlocks: 4.19.0, 5.0.0\n<\/code><\/pre>\n\n\n\n<p><strong>When to use tilde<\/strong>: When you want the most stability in your code and trust the package publisher that their patch updates won&#8217;t break your code&nbsp;<em>(which they shouldn&#8217;t, according to semantic versioning)<\/em>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Caret (^): Minor and Patch Updates<\/h3>\n\n\n\n<p>The caret symbol is more flexible and is considered a&nbsp;<strong>default in<\/strong>&nbsp;<code>npm<\/code>. It allows updates for both minor and patch versions, but&nbsp;<strong>NOT<\/strong>&nbsp;major versions.<\/p>\n\n\n\n<p>If you have&nbsp;mentioned&nbsp;<strong><code>\"express\": \"^4.18.2\"<\/code><\/strong>, in the absence of&nbsp;<code>package-lock.json<\/code>&nbsp;file&nbsp;<code>npm<\/code>&nbsp;can install&nbsp;<code>4.18.2<\/code>,&nbsp;<code>4.18.3<\/code>,&nbsp;<code>4.19.0<\/code>,&nbsp;<code>4.20.0<\/code>, or any other&nbsp;<code>4.x.x<\/code>&nbsp;version. However, it will&nbsp;<strong>NOT<\/strong>&nbsp;install&nbsp;<code>5.0.0<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>text^4.18.2  \u2192  Allows: 4.18.2, 4.18.3, 4.19.0, 4.20.0, 4.99.0...\n\t\tBlocks: 5.0.0<\/code><\/pre>\n\n\n\n<p><strong>When to use caret<\/strong>: When you want the new features and bug fixes of a particular dependency package but want to avoid major version changes that might break your code.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Special Rules for 0.x.x Versions<\/h2>\n\n\n\n<p>Packages with versions below&nbsp;<code>1.0.0<\/code>&nbsp;are considered unstable, these are usually new packages that may just have been published. The rules slightly change for such packages.<\/p>\n\n\n\n<p>For&nbsp;<strong><code>^0.2.5<\/code><\/strong>, the caret behaves like a tilde\u2014it only allows patch updates.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>text^0.2.5   \u2192  Allows: 0.2.5, 0.2.6, 0.2.7...\n\t\tBlocks: 0.3.0, 1.0.0<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">npm install vs npm ci: When to Use Each<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">npm install: Development Workflow<\/h3>\n\n\n\n<p><strong><code>npm install<\/code><\/strong>&nbsp;(short version:&nbsp;<strong><code>npm i<\/code><\/strong>) is the command you would want to use during development.<\/p>\n\n\n\n<p>This command:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Installs new dependencies listed in\u00a0<strong><code>package.json<\/code>\u00a0.<\/strong><\/li>\n\n\n\n<li>Update existing dependencies to compatible newer versions.<\/li>\n\n\n\n<li>Create or update\u00a0<strong><code>package-lock.json<\/code><\/strong>\u00a0if dependencies have changed.<\/li>\n\n\n\n<li>Allow partial installations (you can install just one package).<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install loggernaut\nOR\nnpm i loggernaut\nOR\nnpm install --save-dev loggernaut\nOR\nnpm i -D loggernaut<\/code><\/pre>\n\n\n\n<p>The command is optimized primarily for&nbsp;<strong>development flexibility<\/strong>&nbsp;than strict reproducibility.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">npm ci: Continuous Integration Environment<\/h3>\n\n\n\n<p><strong><code>npm ci<\/code><\/strong>&nbsp;stands for&nbsp;<strong>&#8220;clean install&#8221;<\/strong>&nbsp;and was introduced in&nbsp;<code>npm<\/code>&nbsp;version&nbsp;<code>5.7.0<\/code>.<\/p>\n\n\n\n<p>It was specifically designed for&nbsp;the use in&nbsp;<strong>automated environments<\/strong>&nbsp;like CI\/CD pipelines, deployment servers, and testing environments.<\/p>\n\n\n\n<p>This command:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Requires a\u00a0<strong><code>package-lock.json<\/code><\/strong>\u00a0file\u00a0<em>(Command will fail without it)<\/em>.<\/li>\n\n\n\n<li>Installs exact versions from\u00a0<strong><code>package-lock.json<\/code><\/strong>\u2014without modifying anything.<\/li>\n\n\n\n<li>Deletes and recreates the entire\u00a0<strong><code>node_modules<\/code><\/strong>\u00a0directory.<\/li>\n\n\n\n<li>Is\u00a0<strong>faster<\/strong>\u00a0than\u00a0<strong><code>npm install<\/code><\/strong>\u00a0.<\/li>\n\n\n\n<li>Throws an error if there are any mismatch of the package versions between the files\u00a0<strong><code>package.json<\/code><\/strong>\u00a0and\u00a0<strong><code>package-lock.json<\/code><\/strong><\/li>\n\n\n\n<li>Is more reliable and deterministic and thus is adviced to use in the production environment application boot process.<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm ci<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Key Differences Summary<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large is-style-default\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"549\" src=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/command_comparison-1024x549.png\" alt=\"Key Differences Summary\" class=\"wp-image-463\" srcset=\"https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/command_comparison-1024x549.png 1024w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/command_comparison-300x161.png 300w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/command_comparison-768x412.png 768w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/command_comparison-1536x823.png 1536w, https:\/\/codebounce.debojyotichatterjee.com\/wp-content\/uploads\/2026\/01\/command_comparison-2048x1098.png 2048w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th><strong>Aspect<\/strong><\/th><th><strong>npm install<\/strong><\/th><th><strong>npm ci<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong>Purpose<\/strong><\/td><td>Development.<\/td><td>Continuous Integration \/ Deployment.<\/td><\/tr><tr><td><strong>Requires package-lock.json<\/strong><\/td><td>No.<\/td><td>Yes (fails without it).<\/td><\/tr><tr><td><strong>Modifies lock file<\/strong><\/td><td>Yes (may update it).<\/td><td>No (read-only).<\/td><\/tr><tr><td><strong>Speed<\/strong><\/td><td>Standard.<\/td><td>Faster.<\/td><\/tr><tr><td><strong>Full project install<\/strong><\/td><td>Optional (can also add single or selected packages).<\/td><td>Required (installs entire project).<\/td><\/tr><tr><td><strong>Error on mismatch<\/strong><\/td><td>Fixes automatically.<\/td><td>Fails with error message.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p><a href=\"\"><\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices<\/h2>\n\n\n\n<p><strong>In development<\/strong>: Always use&nbsp;<strong><code>npm install<\/code><\/strong>&nbsp;to manage your dependencies flexibly.<\/p>\n\n\n\n<p><strong>In CI\/CD pipelines<\/strong>: Use&nbsp;<strong><code>npm ci<\/code><\/strong>&nbsp;to ensure fast, reliable, and reproducible builds.<\/p>\n\n\n\n<p><strong>In Docker containers and deployment<\/strong>: Use&nbsp;<strong><code>npm ci<\/code><\/strong>&nbsp;to guarantee the exact same dependencies every time.<\/p>\n\n\n\n<p>Here&#8217;s a typical Dockerfile pattern:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>FROM node:18-alpine\nWORKDIR \/app\nCOPY package.json package-lock.json .\/\nRUN npm ci --only=production\nCOPY . .\nCMD &#91;\"node\", \"server.js\"]\n\n\/* Command Explanation:\n* Sets the base image as Node.js version 18 on an Alpine Linux distribution for smaller size.\n* Sets the working directory inside the container to \/app.\n* Copies package.json and package-lock.json from the local filesystem to the working directory in the container.\n* Installs the project's dependencies specified in package-lock.json for production use, ensuring a clean install.\n* Copies all remaining files from the local directory to the current working directory in the container.\n* Specifies the command to run the application using Node.js to start server.js.\n*\/<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Practical Examples and Terminal Commands<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Setting Up a New Project<\/h3>\n\n\n\n<p>Create a new project directory and initialize npm:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>mkdir my-web-app\ncd my-web-app\nnpm init -y<\/code><\/pre>\n\n\n\n<p>This creates a basic&nbsp;<strong><code>package.json<\/code><\/strong>&nbsp;and it now contains these dependencies, and a&nbsp;<strong><code>package-lock.json<\/code><\/strong>&nbsp;file has also been generated.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Adding and Updating Dependencies<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To add\/install a package:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install loggernaut\nOR\nnpm i loggernaut<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To add\/install a package as development dependency:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install --save-dev loggernaut\nOR\nnpm i -D loggernaut<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To add a specific version of a package:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install loggernaut@1.2.1<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To update all dependencies to their latest compatible versions:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm update<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To update a specific package:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm update loggernaut<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Checking Installed Packages<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To view your installed dependencies and their versions:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm list\nOR\nnpm list --depth=0  # Only shows direct dependencies<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To view outdated packages:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm outdated<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Removing Dependencies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To remove a package:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm uninstall loggernaut\nOR\nnpm rm loggernaut<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Working with package-lock.json<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you accidentally delete\u00a0<code>package-lock.json<\/code>, regenerate it:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install --package-lock-only<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>To force updating the lock file without installing dependencies:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm i --package-lock-only<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Security Auditing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Check your dependencies for known vulnerabilities:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Automatically fix vulnerabilities where possible:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>npm audit fix<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices for package.json and package-lock.json<\/h2>\n\n\n\n<p><strong>1. Always Commit package-lock.json<\/strong><\/p>\n\n\n\n<p>Always include&nbsp;<strong><code>package-lock.json<\/code><\/strong>&nbsp;in your version control system (Git). This ensures all team members and deployment environments use the same exact versions.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># In your .gitignore, make sure package-lock.json is **NOT** ignored\n# Leave this line commented or remove it if it exists:\n# package-lock.json<\/code><\/pre>\n\n\n\n<p><strong>2. Use Semantic Versioning Wisely<\/strong><\/p>\n\n\n\n<p>For public packages, follow semantic versioning strictly. For private applications, caret (^) is usually the right choice as it balances safety with access to bug fixes.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"dependencies\": {\n    \"express\": \"^4.18.2\",        \/\/ Allow minor updates\n    \"lodash\": \"~4.17.21\",        \/\/ Patch updates only for stability\n    \"critical-lib\": \"1.0.0\"      \/\/ Exact version for critical packages\n  }\n}<\/code><\/pre>\n\n\n\n<p><strong>3. Regularly Audit Dependencies<\/strong><\/p>\n\n\n\n<p>Use&nbsp;<strong><code>npm audit<\/code><\/strong>&nbsp;to identify security vulnerabilities and keep dependencies up to date.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Weekly or monthly security checks\nnpm audit\nnpm audit fix<\/code><\/pre>\n\n\n\n<p><strong>4. Clean Up Unused Dependencies<\/strong><\/p>\n\n\n\n<p>Regularly remove dependencies your project no longer uses. Many projects accumulate unused dependencies over time.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm prune  # Removes packages not listed in package.json<\/code><\/pre>\n\n\n\n<p><strong>5. Use npm ci in CI\/CD Pipelines<\/strong><\/p>\n\n\n\n<p>Always use&nbsp;<strong><code>npm ci<\/code><\/strong>&nbsp;instead of&nbsp;<strong><code>npm install<\/code><\/strong>&nbsp;in automated environments to ensure reproducible builds.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Example GitHub Actions workflow\nname: CI\non: &#91;push]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v2\n      - uses: actions\/setup-node@v2\n      - run: npm ci\n      - run: npm test\n      - run: npm run build<\/code><\/pre>\n\n\n\n<p><strong>6. Document Dependencies in package.json<\/strong><\/p>\n\n\n\n<p>Add meaningful keywords, description, and repository information to help other developers understand your project:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"name\": \"express-api\",\n  \"version\": \"1.0.0\",\n  \"description\": \"RESTful API built with Express.js\",\n  \"keywords\": &#91;\"api\", \"rest\", \"nodejs\", \"express\"],\n  \"repository\": \"&lt;https:\/\/github.com\/yourname\/express-api>\",\n  \"bugs\": \"&lt;https:\/\/github.com\/yourname\/express-api\/issues>\",\n  \"homepage\": \"&lt;https:\/\/github.com\/yourname\/express-api#readme>\"\n}<\/code><\/pre>\n\n\n\n<p><strong>7. Manage Dev and Production Dependencies Separately<\/strong><\/p>\n\n\n\n<p>Keep development tools separate from production dependencies to reduce bundle size:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"dependencies\": {\n    \"express\": \"^4.18.2\",\n    \"cors\": \"^2.8.5\"\n  },\n  \"devDependencies\": {\n    \"jest\": \"^29.0.0\",\n    \"nodemon\": \"^2.0.20\",\n    \"eslint\": \"^8.25.0\"\n  }\n}<\/code><\/pre>\n\n\n\n<p><strong>8. Lock Specific Versions for Critical Dependencies<\/strong><\/p>\n\n\n\n<p>For libraries that directly impact security or stability, consider using exact versions:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n  \"dependencies\": {\n    \"bcryptjs\": \"2.4.3\",          \/\/ Security critical - exact version\n    \"express\": \"^4.18.2\",        \/\/ Application framework - minor updates ok\n    \"dotenv\": \"^16.0.3\"          \/\/ Configuration - minor updates ok\n  }\n}<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>If you\u2019re working with Node.js, you can\u2019t ignore&nbsp;<code>package.json<\/code>&nbsp;and&nbsp;<code>package-lock.json<\/code>. These two files shape how your project runs, how your team works together, and even how smooth your deployments go.<\/p>\n\n\n\n<p><strong>Here\u2019s what matters:<\/strong><\/p>\n\n\n\n<p><code>package.json<\/code>&nbsp;lists your project\u2019s dependencies. It uses symbols like ^ and ~ for version ranges, so you get a bit of flexibility\u2014updates, but under control.<\/p>\n\n\n\n<p><code>package-lock.json<\/code>, on the other hand, nails down the exact versions. This means if you\u2014or anyone else\u2014install dependencies, you all end up with the same versions. No surprises, no \u201cbut it worked on my machine\u201d headaches.<\/p>\n\n\n\n<p>During development, stick with&nbsp;<code>npm<\/code>&nbsp;install. It keeps things flexible. When you\u2019re running builds or tests in CI\/CD pipelines, though, switch to&nbsp;<code>npm ci<\/code>. It\u2019s faster and locks in versions, so you know exactly what\u2019s getting installed.<\/p>\n\n\n\n<p>Commit&nbsp;<code>package-lock.json<\/code>&nbsp;to your repo. Seriously. It keeps everyone on the same page, every time.<\/p>\n\n\n\n<p><strong>A few more tips:<\/strong>&nbsp;run&nbsp;<code>npm audit<\/code>&nbsp;to catch security issues, keep dev dependencies separate, and document your project\u2014it saves time for everyone.<\/p>\n\n\n\n<p>Get comfortable with these two files and you\u2019ll sidestep a lot of pain. Clean dependency management isn\u2019t just for big projects. Whether you\u2019re hacking on a side project or shipping code in production,&nbsp;<code>package.json<\/code>&nbsp;and&nbsp;<code>package-lock.json<\/code>&nbsp;are the backbone of reliable Node.js development.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Additional Resources<\/h2>\n\n\n\n<p>Here are valuable external resources to deepen your understanding:<\/p>\n\n\n\n<p><strong>Official npm Documentation<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/docs.npmjs.com\/cli\/v11\/configuring-npm\/package-json\/\">npm package.json Documentation<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/docs.npmjs.com\/cli\/v11\/configuring-npm\/package-lock-json\/\">npm package-lock.json Documentation<\/a><\/li>\n<\/ul>\n\n\n\n<p><strong>Security and Best Practices<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cheatsheetseries.owasp.org\/cheatsheets\/NPM_Security_Cheat_Sheet.html\">OWASP NPM Security Cheat Sheet<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/docs.npmjs.com\/cli\/v8\/commands\/npm-audit\/\">npm Audit Guide for Vulnerability Management<\/a><\/li>\n<\/ul>\n\n\n\n<p><strong>Semantic Versioning<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/semver.org\/\">Semantic Versioning Official Guide<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/semver.npmjs.com\/\">npm semver Calculator Tool<\/a><\/li>\n<\/ul>\n\n\n\n<p><strong>Continuous Integration and Deployment<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/docs.npmjs.com\/cli\/v9\/commands\/npm-ci\/\">npm ci Command Official Documentation<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/github.com\/actions\/setup-node\">GitHub Actions: Node.js Setup Guide<\/a><\/li>\n<\/ul>\n\n\n\n<p><strong>Community Resources<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/stackoverflow.com\/questions\/tagged\/package.json\">Stack Overflow: package.json Tag<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/blog.npmjs.org\/\">npm Blog: Latest Updates and Best Practices<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>When you are building on any JavaScript application (for example&nbsp;Node.js or ReactJS), you quickly discover two files&nbsp;package.json&nbsp;and&nbsp;package-lock.json.&nbsp;These two files are very important and form the backbone of dependency management in your project to ensure your project runs smoothly whether you&#8217;re developing locally or deploying to a server. Think of&nbsp;package.json&nbsp;as your project&#8217;s&nbsp;identity.&nbsp;This file contains essential information [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":458,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-454","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/posts\/454","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/comments?post=454"}],"version-history":[{"count":5,"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/posts\/454\/revisions"}],"predecessor-version":[{"id":468,"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/posts\/454\/revisions\/468"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/media\/458"}],"wp:attachment":[{"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/media?parent=454"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/categories?post=454"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codebounce.debojyotichatterjee.com\/index.php\/wp-json\/wp\/v2\/tags?post=454"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}