mirror of
https://github.com/freeCodeCamp/freeCodeCamp.git
synced 2026-02-16 13:00:30 -05:00
feat(curriculum): add intro to npm lessons (#64993)
Co-authored-by: Zaira <33151350+zairahira@users.noreply.github.com> Co-authored-by: Dario <105294544+Dario-DC@users.noreply.github.com> Co-authored-by: Kolade Chris <65571316+Ksound22@users.noreply.github.com>
This commit is contained in:
majestic-owl448
@@ -7691,6 +7691,12 @@
|
||||
"Learn the fundamentals of how web communication works through the HTTP request-response model, explore different types of web assets and responses, and understand how forms handle data submission using various HTTP methods."
|
||||
]
|
||||
},
|
||||
"lecture-introduction-to-npm": {
|
||||
"title": "Introduction to npm",
|
||||
"intro": [
|
||||
"In these lessons, you will learn about npm, and how it can help you manage your project's dependencies."
|
||||
]
|
||||
},
|
||||
"lecture-working-with-npm-scripts": {
|
||||
"title": "Working with npm Scripts",
|
||||
"intro": [
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Introduction to the Introduction to npm
|
||||
block: lecture-introduction-to-npm
|
||||
superBlock: back-end-development-and-apis-v9
|
||||
---
|
||||
|
||||
## Introduction to the Introduction to npm
|
||||
|
||||
In these lessons, you will learn about npm, and how it can help you manage your project's dependencies.
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
id: 695b93b7d61d4520790c3903
|
||||
title: What Is npm?
|
||||
challengeType: 19
|
||||
dashedName: what-is-npm
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
When you build projects in JavaScript, you often need extra tools to help you get things done. Even simple apps may need features like saving data, logging in, routing to move between pages, and so on.
|
||||
|
||||
Instead of writing all of this code from scratch, you can use open-source packages that other developers have already built and shared.
|
||||
|
||||
This is where npm comes in. npm is a huge online registry of open-source software. Think of it like an app store for code — you can search for what you need, install it, and start using it in your project.
|
||||
|
||||
Many people think npm stands for "Node Package Manager," but that's not its official meaning. In older npm documentation, it was described as a "recursive bacronymic abbreviation for 'npm is not an acronym.'" In other words, npm doesn't officially stand for anything.
|
||||
|
||||
Today, npm refers to three related parts:
|
||||
|
||||
* The website npmjs.com, where you can look up packages in the registry.
|
||||
|
||||
* The npm registry, which is a large public database that stores all the packages.
|
||||
|
||||
* The npm CLI tool that's installed with Node.js and lets you install and manage packages.
|
||||
|
||||
|
||||
For example, if you need to manage state, handle dates, send emails, or make HTTP requests in your project, there's probably an npm package that already does that. With a simple `npm install` command, you can start using this ready-made software instead of doing all the work yourself.
|
||||
|
||||
npm also helps you manage your project dependencies. This means it keeps track of the packages you use in your projects, and the version of each of those packages. It does this with the `package.json` and `package-lock.json` files, which you'll learn about in future lessons.
|
||||
|
||||
Yarn, PNPM, and Bun are some alternatives to npm that have become popular over time. While each of them offer benefits in specific areas like installation speed and storage efficiency, npm is still the most widely used.
|
||||
|
||||
In upcoming lessons, you'll learn various npm commands, how to install packages, about the `package.json` and `package-lock.json` files, and even how to publish your own package to the npm registry.
|
||||
|
||||
# --questions--
|
||||
|
||||
## --text--
|
||||
|
||||
What does npm provide to developers?
|
||||
|
||||
## --answers--
|
||||
|
||||
A platform for deploying websites directly to the cloud.
|
||||
|
||||
### --feedback--
|
||||
|
||||
It helps developers avoid reinventing the wheel by using ready-made solutions.
|
||||
|
||||
---
|
||||
|
||||
A browser-based tool for testing APIs.
|
||||
|
||||
### --feedback--
|
||||
|
||||
It helps developers avoid reinventing the wheel by using ready-made solutions.
|
||||
|
||||
---
|
||||
|
||||
A database system for storing user data.
|
||||
|
||||
### --feedback--
|
||||
|
||||
It helps developers avoid reinventing the wheel by using ready-made solutions.
|
||||
|
||||
---
|
||||
|
||||
A registry of prebuilt software packages that solves common problems.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
4
|
||||
|
||||
## --text--
|
||||
|
||||
Which of the following is *not* one of the three parts that npm refers to?
|
||||
|
||||
## --answers--
|
||||
|
||||
The website, npmjs.com
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the three main components that make up npm and how they all work together.
|
||||
|
||||
---
|
||||
|
||||
The Node.js runtime
|
||||
|
||||
---
|
||||
|
||||
The package registry
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the three main components that make up npm and how they all work together.
|
||||
|
||||
---
|
||||
|
||||
The command-line tool
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the three main components that make up npm and how they all work together.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
2
|
||||
|
||||
## --text--
|
||||
|
||||
What does the `npm install` command allow you to do?
|
||||
|
||||
## --answers--
|
||||
|
||||
Create a new Node.js project from scratch
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how developers reuse existing solutions instead of writing everything from scratch.
|
||||
|
||||
---
|
||||
|
||||
Run your Node.js application on a local server
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how developers reuse existing solutions instead of writing everything from scratch.
|
||||
|
||||
---
|
||||
|
||||
Add prebuilt packages to your project for common tasks
|
||||
|
||||
---
|
||||
|
||||
Uninstall unused dependencies from your project
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how developers reuse existing solutions instead of writing everything from scratch.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
@@ -0,0 +1,250 @@
|
||||
---
|
||||
id: 695b93cb572125a6fb19f399
|
||||
title: What Is a package.json File
|
||||
challengeType: 19
|
||||
dashedName: what-is-a-package-json-file
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
npm needs a way to store important details about your project – things like what packages it uses, the version of those packages, and what commands it can run. It does this with the `package.json` file.
|
||||
|
||||
Think of the `package.json` file as an npm configuration file for the project. It's a simple JSON file that describes your project using key-value pairs to keep track of things like:
|
||||
|
||||
* the project's name and version
|
||||
|
||||
* the author
|
||||
|
||||
* the main file that should be run first
|
||||
|
||||
* the license
|
||||
|
||||
* the code repository, keywords, and descriptions
|
||||
|
||||
* any dependencies the project needs
|
||||
|
||||
|
||||
Here's what a `package.json` file might look like:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "my-app",
|
||||
"version": "1.0.0",
|
||||
"description": "A simple NPM project",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"start": "node index.js",
|
||||
"test": "echo \"Running tests...\""
|
||||
},
|
||||
"repository": {
|
||||
"type": "git",
|
||||
"url": "git+https://github.com/username/project.git"
|
||||
},
|
||||
"keywords": ["fCC", "js"],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"react": "^19.2.1"
|
||||
},
|
||||
"devDependencies": {
|
||||
"cypress": "^15.7.1"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The `main` field is often set to `index.js`, and tells Node.js which file to run first.
|
||||
|
||||
The `license` field is used to specify the legal terms under which other people can use, modify, and distribute the code in your package. There are many different licenses like `MIT`, `ISC`, or `GPL`, which all have different terms and permissions. The default is `ISC`, the Internet Systems Consortium License, which is a very permissive open source license.
|
||||
|
||||
As your project grows and you install packages, npm adds them under one of two sections:
|
||||
|
||||
* `dependencies`, which are packages your app needs to run in production
|
||||
|
||||
* `devDependencies`, which are packages you only need during development
|
||||
|
||||
|
||||
For example, if your project uses React for its UI, that goes in `dependencies` because it's required for your project to work once it's deployed. A tool like Cypress, which is only used for end-to-end testing before deploying to production, belongs in `devDependencies`.
|
||||
|
||||
There are a couple of easy ways to create a `package.json` file. The most common way is to run the following command:
|
||||
|
||||
```bash
|
||||
npm init
|
||||
```
|
||||
|
||||
You should run this in the root folder of your project. This command starts an interactive setup process where npm asks you a series of questions. Your answers are used to fill in fields like the project's name, version, description, scripts, keywords, author, and license.
|
||||
|
||||
If you prefer to skip the questions and create a `package.json` file with default values, you can run:
|
||||
|
||||
```bash
|
||||
npm init -y
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```bash
|
||||
npm init --yes
|
||||
```
|
||||
|
||||
This instantly creates a `package.json` file for you with default values in many fields.
|
||||
|
||||
It's usually best to use `npm init` without the `-y` or `--yes` flag so you can go through each field and customize your project's information. If you don't answer a question, npm simply uses a default value. For example, if you leave the license question empty, npm will set it to `ISC` by default.
|
||||
|
||||
Here's an example of what you'll see when running `npm init`:
|
||||
|
||||
```bash
|
||||
user@Kolade ~/Desktop/fCC/npm/package-json-file % npm init
|
||||
It only covers the most common items, and tries to guess sensible defaults.
|
||||
|
||||
See `npm help init` for definitive documentation on these fields
|
||||
and exactly what they do.
|
||||
|
||||
Use `npm install <pkg>` afterwards to install a package and
|
||||
save it as a dependency in the package.json file.
|
||||
|
||||
Press ^C at any time to quit.
|
||||
package name: (test) my-app
|
||||
version: (1.0.0)
|
||||
description: a description for my-app
|
||||
entry point: (index.js)
|
||||
test command:
|
||||
git repository:
|
||||
keywords: fCC, JS
|
||||
author: Kolade Chris
|
||||
license: (ISC)
|
||||
About to write to /Users/user/Desktop/fCC/npm/package-json-file/package.json
|
||||
|
||||
{
|
||||
"name": "my-app",
|
||||
"version": "1.0.0",
|
||||
"description": "a description for my-app",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": [
|
||||
"fCC",
|
||||
"JS"
|
||||
],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC"
|
||||
}
|
||||
|
||||
|
||||
Is this OK? (yes)
|
||||
```
|
||||
|
||||
You might notice that `dependencies` and `devDependencies` aren't listed yet. That's because these sections are only added after you install your first package.
|
||||
|
||||
You'll also notice that the `repository` field is missing. Even though npm asked about it during `npm init`, it doesn't automatically fill it in later. For example, when you run commands like `git remote add origin` or `git push`, npm won't update the repository field for you — you have to add it manually if you want it included.
|
||||
|
||||
In the next lessons, you'll learn more about dependencies in `package.json` and how to install, update, and remove them.
|
||||
|
||||
# --questions--
|
||||
|
||||
## --text--
|
||||
|
||||
How can you create a `package.json` file?
|
||||
|
||||
## --answers--
|
||||
|
||||
Only by downloading it from the npm website.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that helps set up project details interactively.
|
||||
|
||||
---
|
||||
|
||||
By running the `npm install` command.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that helps set up project details interactively.
|
||||
|
||||
---
|
||||
|
||||
By running the `npm init` command.
|
||||
|
||||
---
|
||||
|
||||
By importing it from another project.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that helps set up project details interactively.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
|
||||
## --text--
|
||||
|
||||
What happens to the `package.json` file when you install dependencies in a Node.js project?
|
||||
|
||||
## --answers--
|
||||
|
||||
It deletes existing configuration keys.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm stores details of installed packages.
|
||||
|
||||
---
|
||||
|
||||
It creates a `dependencies` or `devDependencies` section based on the type of package installed.
|
||||
|
||||
---
|
||||
|
||||
It automatically updates the project's version number.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm stores details of installed packages.
|
||||
|
||||
---
|
||||
|
||||
It removes unused packages from the project.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm stores details of installed packages.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
2
|
||||
|
||||
## --text--
|
||||
|
||||
Which of the following information does the `package.json` file store in a Node.js project?
|
||||
|
||||
## --answers--
|
||||
|
||||
Details like project `name`, `version`, `author`, entry file, and `license`
|
||||
|
||||
---
|
||||
|
||||
Only the project's CSS styles and HTML templates
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what helps identify and describe a Node.js project.
|
||||
|
||||
---
|
||||
|
||||
The compiled JavaScript output files
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what helps identify and describe a Node.js project.
|
||||
|
||||
---
|
||||
|
||||
User credentials and system environment variables
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what helps identify and describe a Node.js project.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
1
|
||||
@@ -0,0 +1,199 @@
|
||||
---
|
||||
id: 695b93cb572125a6fb19f39a
|
||||
title: What Are Package Dependencies and What Are Some Considerations for Choosing an External Package?
|
||||
challengeType: 19
|
||||
dashedName: what-are-package-dependencies-and-what-are-some-considerations-for-choosing-an-external-package
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
In an earlier lesson, you learned what dependencies are. Here, you'll learn more about them and things to consider when choosing an external package to use for your project.
|
||||
|
||||
A dependency is another piece of code your project needs in order to work. These are usually external packages that other developers have created and shared in the npm registry.
|
||||
|
||||
Using dependencies saves you a lot of time. Instead of building everything yourself, you can install a package that already solves a common problem — things like creating a web server, handling routing, fetching data, managing authentication, and more.
|
||||
|
||||
In your `package.json` file, all the packages your project depends on are listed under the `dependencies` key:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "package-dependencies",
|
||||
"version": "1.0.0",
|
||||
"description": "a demo on how package dependencies work",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": [
|
||||
"Node",
|
||||
"NPM"
|
||||
],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"chalk": "^5.6.2",
|
||||
"lodash": "^4.17.21"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In the example `package.json` file above, `chalk` and `lodash` are listed as the project's dependencies. That means the project relies on these packages to work. If they're not installed—and listed in the `package.json` file—any features that use them will break.
|
||||
|
||||
There's also another category of dependencies called `devDependencies`. These are packages you only need while building or testing your project, not when it's running in production. Common examples include:
|
||||
|
||||
* Nodemon for automatically restarting the project when there are updates
|
||||
|
||||
* Jest or Mocha for testing
|
||||
|
||||
* ESLint for code linting
|
||||
|
||||
|
||||
As you'd expect, `devDependencies` appear under the `devDependencies` section of the `package.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "package-dependencies",
|
||||
"version": "1.0.0",
|
||||
"description": "a demo on how package dependencies work",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": [
|
||||
"Node",
|
||||
"NPM"
|
||||
],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"chalk": "^5.6.2",
|
||||
"lodash": "^4.17.21"
|
||||
},
|
||||
"devDependencies": {
|
||||
"jest": "^30.2.0",
|
||||
"nodemon": "^3.1.10"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When choosing which packages to use in your project, there are a few important things to keep in mind.
|
||||
|
||||
Security should always come first. Even a single unsafe package can create problems for your entire project. You should also consider performance, because a large or poorly optimized package can slow your project down.
|
||||
|
||||
It also helps to choose packages that are popular and well-supported. Popular packages usually have active communities, good documentation, and frequent updates. One easy way to check popularity is to look at the number of weekly downloads on npm. For example, the `chalk` package gets over 300,000 downloads each week:
|
||||
|
||||
<img src="https://cdn.freecodecamp.org/curriculum/lecture-transcripts/what-are-package-dependencies-and-what-are-some-considerations-for-choosing-an-external-package-1.webp" alt="screenshot from npm of chalk package statistics">
|
||||
|
||||
Maintenance is important too. Well-maintained packages are updated regularly and work better with new versions of other software.
|
||||
|
||||
Finally, don't overlook documentation. Clear, thorough docs make it much easier to understand how to use a package and save you a lot of time when integrating it into your project.
|
||||
|
||||
# --questions--
|
||||
|
||||
## --text--
|
||||
|
||||
What does a high number of downloads for an npm package usually indicate?
|
||||
|
||||
## --answers--
|
||||
|
||||
The package is new and untested.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what a high download count says about a package's popularity.
|
||||
|
||||
---
|
||||
|
||||
The package is unpopular and rarely used.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what a high download count says about a package's popularity.
|
||||
|
||||
---
|
||||
|
||||
The package has strong community support and is likely more reliable.
|
||||
|
||||
---
|
||||
|
||||
The package is only used for private projects.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what a high download count says about a package's popularity.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
|
||||
## --text--
|
||||
|
||||
Which statement best describes the difference between `dependencies` and `devDependencies`?
|
||||
|
||||
## --answers--
|
||||
|
||||
`dependencies` are only used for testing, while `devDependencies` are used in production.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about which type of dependency is required for the app to function after deployment.
|
||||
|
||||
---
|
||||
|
||||
`dependencies` are needed for the app to run, while `devDependencies` are only needed during development and testing.
|
||||
|
||||
---
|
||||
|
||||
`devDependencies` are automatically installed in production environments.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about which type of dependency is required for the app to function after deployment.
|
||||
|
||||
---
|
||||
|
||||
`devDependencies` are only for managing databases.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about which type of dependency is required for the app to function after deployment.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
2
|
||||
|
||||
## --text--
|
||||
|
||||
Why are dependencies useful?
|
||||
|
||||
## --answers--
|
||||
|
||||
They slow down project setup to ensure clean coding practices.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how dependencies help you avoid reinventing the wheel.
|
||||
|
||||
---
|
||||
|
||||
They prevent developers from installing third-party packages.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how dependencies help you avoid reinventing the wheel.
|
||||
|
||||
---
|
||||
|
||||
They are required only for styling and front-end design.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how dependencies help you avoid reinventing the wheel.
|
||||
|
||||
---
|
||||
|
||||
They provide ready-made solutions for common tasks like routing and authentication.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
4
|
||||
@@ -0,0 +1,180 @@
|
||||
---
|
||||
id: 695b93cb572125a6fb19f39b
|
||||
title: What Is Semantic Versioning?
|
||||
challengeType: 19
|
||||
dashedName: what-is-semantic-versioning
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Semantic versioning, or SemVer, is a system that gives version numbers a clear meaning, so developers can quickly understand what kind of changes were made to software.
|
||||
|
||||
SemVer uses this format:
|
||||
|
||||
```bash
|
||||
MAJOR.MINOR.PATCH
|
||||
```
|
||||
|
||||
For example, the popular library `lodash` is currently version `4.17.21`.
|
||||
|
||||
Here's what each part means:
|
||||
|
||||
* MAJOR — Large changes that break existing code. Example: removing or renaming a function that existing code might depend on.
|
||||
|
||||
* MINOR — New features that don't break existing code. Example: adding a new function or optional parameter.
|
||||
|
||||
* PATCH — Small fixes and improvements. Example: fixing a bug or typo without changing how anything works.
|
||||
|
||||
|
||||
<img src="https://cdn.freecodecamp.org/curriculum/lecture-transcripts/what-is-semantic-versioning-1.png" alt="In the version number 4.17.21, 4 is the Major Version, it's changed for breaking changes, the 17 is the minor version, it's changed for non-breaking changes, and the 21 is the patch, it's changed for bug fixes and small features">
|
||||
|
||||
Let's say you have a package called `my-package`. Here's an example of how its version number might change over time using semantic versioning:
|
||||
|
||||
| Version | What Changed |
|
||||
| --- | --- |
|
||||
| 1.0.0 | Initial stable release |
|
||||
| 1.1.0 | New optional feature |
|
||||
| 1.1.1 | Small bug fix or feature |
|
||||
| 2.0.0 | Breaking changes introduced |
|
||||
|
||||
But there's more to version numbers in npm. When you install a package, the version in your `package.json` file might look like this:
|
||||
|
||||
```json
|
||||
"lodash": "^4.17.21"
|
||||
```
|
||||
|
||||
You already learned that `4` is the major version, `17` is the minor version, and `21` is the patch version. But what does the caret (`^`) in front mean?
|
||||
|
||||
The caret symbol allows npm to automatically install newer minor and patch versions (`4.x.x`), but not newer major versions (`5.x.x`), because major updates may include breaking changes.
|
||||
|
||||
When the major version is `0`, the caret becomes more restrictive. For example, `^0.2.3` would allow updates like `0.2.4`, but not `0.3.0`, since major versions starting with `0` are considered less stable.
|
||||
|
||||
The caret is not the only symbol `npm` and other JavaScript package managers use for managing dependency versions.
|
||||
|
||||
There is the tilde symbol (`~`) which allows updates to the patch version only. So, `~1.2.3` would accept `1.2.4` and `1.2.9`, but never `1.3.0`.
|
||||
|
||||
You can also use the greater than (`>`), lesser than (`<`), and their "or equals" equivalents to accept versions between a range. For example, `>=1.2.3 <2.0.0` means any version from `1.2.3` up to, but not including, `2.0.0`.
|
||||
|
||||
The asterisk symbol (`*`), matches any version, so it accepts everything. This is ideal only for testing and not recommended for production.
|
||||
|
||||
Finally, you can lock down an exact version by not prefixing the version number with any symbol. For instance, version `1.2.3` accepts only `1.2.3`.
|
||||
|
||||
Here's a quick summary table:
|
||||
|
||||
| Symbol | Meaning | Example Range |
|
||||
| --- | --- | --- |
|
||||
| `^` | Allow minor + patch updates | `^1.2.3` → `1.x.x` |
|
||||
| `~` | Allow patch updates only | `~1.2.3` → `1.2.x` |
|
||||
| `>`, `<`, `>=`, `<=` | Custom range | `>=1.2.3` or `<2.0.0` |
|
||||
| **\*** | Any version | all versions |
|
||||
| none | Exact version | `1.2.3` |
|
||||
|
||||
# --questions--
|
||||
|
||||
## --text--
|
||||
|
||||
What does a major version indicate in semantic versioning?
|
||||
|
||||
## --answers--
|
||||
|
||||
Minor improvements or added features that don't break existing code.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what happens when you rename or remove a function already used in your project.
|
||||
|
||||
---
|
||||
|
||||
Bug fixes that don't affect the functionality.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what happens when you rename or remove a function already used in your project.
|
||||
|
||||
---
|
||||
|
||||
Breaking changes that can cause existing code to stop working.
|
||||
|
||||
---
|
||||
|
||||
Updates to documentation or comments only.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about what happens when you rename or remove a function already used in your project.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
|
||||
## --text--
|
||||
|
||||
If a version number is `5.18.4`, which part represents the patch version?
|
||||
|
||||
## --answers--
|
||||
|
||||
`4`
|
||||
|
||||
---
|
||||
|
||||
`18`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the `MAJOR.MINOR.PATCH` order.
|
||||
|
||||
---
|
||||
|
||||
`5`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the `MAJOR.MINOR.PATCH` order.
|
||||
|
||||
---
|
||||
|
||||
All of them
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the `MAJOR.MINOR.PATCH` order.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
1
|
||||
|
||||
## --text--
|
||||
|
||||
What does the tilde (`~`) symbol mean in semantic versioning?
|
||||
|
||||
## --answers--
|
||||
|
||||
It allows updates to both minor and major versions.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about which part of the version number can change when using `~1.2.3`.
|
||||
|
||||
---
|
||||
|
||||
It allows updates to the major version only.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about which part of the version number can change when using `~1.2.3`.
|
||||
|
||||
---
|
||||
|
||||
It locks the dependency to a specific version.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about which part of the version number can change when using `~1.2.3`.
|
||||
|
||||
---
|
||||
|
||||
It allows updates to the patch version only.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
4
|
||||
@@ -0,0 +1,331 @@
|
||||
---
|
||||
id: 695b93cb572125a6fb19f39c
|
||||
title: How Can You Install and Remove Dependencies?
|
||||
challengeType: 19
|
||||
dashedName: how-can-you-install-and-remove-dependencies
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
In a previous lesson, you learned what dependencies are and how to choose the right ones for your project.
|
||||
|
||||
In this lesson, you'll learn how to install and remove dependencies using npm.
|
||||
|
||||
To install a dependency, use the `npm install` command like this:
|
||||
|
||||
```bash
|
||||
npm install dependencyName
|
||||
```
|
||||
|
||||
You can also shorten `install` to `i` like this:
|
||||
|
||||
```bash
|
||||
npm i dependencyName
|
||||
```
|
||||
|
||||
After installing a package, npm adds a new `dependencies` section to your `package.json` file (if it isn't already there) and lists the package you installed. For example, here's what it looks like when you install the `chalk` package:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "install-uninstall-deps",
|
||||
"version": "1.0.0",
|
||||
"description": "a simple demo on how to install and uninstall dependencies",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": ["npm", "deps"],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"chalk": "^5.6.2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When you install a dependency, two new things appear in your project's root folder:
|
||||
|
||||
* `node_modules/`: a folder that contains the actual code for the packages you installed.
|
||||
|
||||
* `package-lock.json`: a file that stores detailed information about the exact versions of those packages, including their own dependencies. (You'll learn more about this file in a later lesson.)
|
||||
|
||||
|
||||
<img src="https://cdn.freecodecamp.org/curriculum/lecture-transcripts/how-can-you-install-and-remove-dependencies-1.png" alt="">
|
||||
|
||||
Most projects need more than one dependency. Instead of installing them one at a time, npm lets you install multiple packages at once by entering a space-separated list of package names:
|
||||
|
||||
```bash
|
||||
npm install express lodash bcrypt
|
||||
```
|
||||
|
||||
Just like before, when you install multiple dependencies at once, npm updates your `package.json` and `package-lock.json` files and your `node_modules` to include them. Here's what the `package.json` would look like:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "install-uninstall-deps",
|
||||
"version": "1.0.0",
|
||||
"description": "a simple demo on how to install and uninstall dependencies",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": ["npm", "deps"],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"bcrypt": "^6.0.0",
|
||||
"chalk": "^5.6.2",
|
||||
"express": "^5.1.0",
|
||||
"lodash": "^4.17.21"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To install a `devDependency`, add the `--save-dev` flag to the `install` command. You can also use the shorter `-D` version:
|
||||
|
||||
```bash
|
||||
npm i nodemon -D
|
||||
```
|
||||
|
||||
After running this command, npm updates your `package.json` file and adds the package under the `devDependencies` section. Here's an example of what that looks like:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "install-uninstall-deps",
|
||||
"version": "1.0.0",
|
||||
"description": "a simple demo on how to install and uninstall dependencies",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": ["npm", "deps"],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"bcrypt": "^6.0.0",
|
||||
"chalk": "^5.6.2",
|
||||
"express": "^5.1.0",
|
||||
"lodash": "^4.17.21"
|
||||
},
|
||||
"devDependencies": {
|
||||
"nodemon": "^3.1.10"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Whenever you run an `npm install` command, npm will show a message telling you whether the installation was successful or not. A success message usually looks something like this:
|
||||
|
||||
```bash
|
||||
user@Kolade ~/Desktop/fCC/script-code/node/npm/install-uninstall-deps % npm install express lodash bcrypt
|
||||
|
||||
added 72 packages, and audited 74 in 8s
|
||||
|
||||
17 packages are looking for funding
|
||||
run `npm fund` for details
|
||||
|
||||
found 0 vulnerabilities
|
||||
|
||||
user@Kolade ~/Desktop/fCC/script-code/node/npm/install-uninstall-deps % npm install nodemon -D
|
||||
|
||||
added 27 packages, and audited 101 in 16s
|
||||
|
||||
21 packages are looking for funding
|
||||
run `npm fund` for details
|
||||
|
||||
found 0 vulnerabilities
|
||||
```
|
||||
|
||||
To uninstall or remove a package, use the `npm uninstall` command:
|
||||
|
||||
```bash
|
||||
npm uninstall dependencyName
|
||||
```
|
||||
|
||||
For example, to remove `chalk` from your project, you'd run this command:
|
||||
|
||||
```bash
|
||||
npm uninstall chalk
|
||||
```
|
||||
|
||||
You can also uninstall multiple packages at once by listing them with spaces between each package name:
|
||||
|
||||
```bash
|
||||
npm uninstall express lodash bcrypt
|
||||
```
|
||||
|
||||
You will also get a message showing whether the uninstall command succeeded or failed:
|
||||
|
||||
```bash
|
||||
user@Kolade ~/Desktop/fCC/script-code/node/npm/install-uninstall-deps % npm uninstall chalk
|
||||
|
||||
added 1 package, removed 1 package, and audited 101 packages in 1s
|
||||
|
||||
20 packages are looking for funding
|
||||
run `npm fund` for details
|
||||
|
||||
found 0 vulnerabilities
|
||||
|
||||
user@Kolade ~/Desktop/fCC/script-code/node/npm/install-uninstall-deps % npm uninstall express lodash bcrypt
|
||||
|
||||
removed 70 packages, and audited 31 in 1s
|
||||
|
||||
4 packages are looking for funding
|
||||
run `npm fund` for details
|
||||
|
||||
found 0 vulnerabilities
|
||||
```
|
||||
|
||||
And your `package.json` file will be updated automatically:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "install-uninstall-deps",
|
||||
"version": "1.0.0",
|
||||
"description": "a simple demo on how to install and uninstall dependencies",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": ["npm", "deps"],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC",
|
||||
"devDependencies": {
|
||||
"nodemon": "^3.1.10"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To uninstall a `devDependency`, you can simply run:
|
||||
|
||||
```bash
|
||||
npm uninstall nodemon
|
||||
```
|
||||
|
||||
Note that you do not need the `-D` flag when uninstalling. npm will automatically remove the package from the correct section, `devDependencies` in this case.
|
||||
|
||||
After uninstalling the `devDependency`, your `package.json` will be updated again:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "install-uninstall-deps",
|
||||
"version": "1.0.0",
|
||||
"description": "a simple demo on how to install and uninstall dependencies",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": ["npm", "deps"],
|
||||
"author": "Kolade Chris",
|
||||
"license": "ISC"
|
||||
}
|
||||
```
|
||||
|
||||
# --questions--
|
||||
|
||||
## --text--
|
||||
|
||||
What happens to your `package.json` file after you install a new dependency like `chalk`?
|
||||
|
||||
## --answers--
|
||||
|
||||
The file is deleted and replaced automatically.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm records the packages your project depends on.
|
||||
|
||||
---
|
||||
|
||||
The package is installed without being recorded anywhere.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm records the packages your project depends on.
|
||||
|
||||
---
|
||||
|
||||
A new dependencies key is added with the package name listed under it.
|
||||
|
||||
---
|
||||
|
||||
The `package.json` file becomes read-only.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm records the packages your project depends on.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
|
||||
## --text--
|
||||
|
||||
Which folder and file are automatically added to your project after installing a dependency?
|
||||
|
||||
## --answers--
|
||||
|
||||
`src` folder and [`readme.md`](http://readme.md) file
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm stores installed packages and tracks their exact versions.
|
||||
|
||||
---
|
||||
|
||||
`node_modules` folder and `package-lock.json` file
|
||||
|
||||
---
|
||||
|
||||
`public` folder and `index.html` file
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm stores installed packages and tracks their exact versions.
|
||||
|
||||
---
|
||||
|
||||
`dist` folder and `webpack.config.js` file
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about where npm stores installed packages and tracks their exact versions.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
2
|
||||
|
||||
## --text--
|
||||
|
||||
Which command correctly installs a `devDependency`?
|
||||
|
||||
## --answers--
|
||||
|
||||
`npm install nodemon -D`
|
||||
|
||||
---
|
||||
|
||||
`npm uninstall nodemon`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the flag used to install development-only dependencies.
|
||||
|
||||
---
|
||||
|
||||
`npm save nodemon --dev`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the flag used to install development-only dependencies.
|
||||
|
||||
---
|
||||
|
||||
`npm install nodemon`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the flag used to install development-only dependencies.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
1
|
||||
@@ -0,0 +1,198 @@
|
||||
---
|
||||
id: 695b93cb572125a6fb19f39d
|
||||
title: How Can You Install Specific Versions and Manage Dependencies?
|
||||
challengeType: 19
|
||||
dashedName: how-can-you-install-specific-versions-and-manage-dependencies
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Keeping your dependencies up to date—and knowing how to install a specific version—is important for keeping your project stable. It helps you avoid unexpected bugs and gives you more control when new versions are released.
|
||||
|
||||
To install a specific version of a package, use this format:
|
||||
|
||||
```bash
|
||||
npm install package@version-number
|
||||
```
|
||||
|
||||
For example, if your project needs an older version of Express, say `4.21.2`, you can install it like this:
|
||||
|
||||
```bash
|
||||
npm install express@4.21.2
|
||||
```
|
||||
|
||||
If you don't include a version number, npm will automatically install the latest version available.
|
||||
|
||||
If you're not sure which versions exist, you can check them with this command:
|
||||
|
||||
```bash
|
||||
npm view package-name versions
|
||||
```
|
||||
|
||||
For instance:
|
||||
|
||||
```bash
|
||||
npm view express versions
|
||||
```
|
||||
|
||||
To update packages, you can update them individually or all at once. Before doing that, it's helpful to first see which ones are out of date:
|
||||
|
||||
```bash
|
||||
npm outdated
|
||||
```
|
||||
|
||||
This will show you which dependencies have newer versions available, and you should see an output similar to this:
|
||||
|
||||
```bash
|
||||
user@Kolade ~/Desktop/fCC/script-code/node/npm/install-spec-version % npm outdated
|
||||
Package Current Wanted Latest Location Depended by
|
||||
chalk 5.5.0 5.5.0 5.6.2 node_modules/chalk install-spec-version
|
||||
cleave 1.0.1 1.0.1 1.0.2 node_modules/cleave install-spec-version
|
||||
express 4.21.2 4.21.2 5.2.1 node_modules/express install-spec-version
|
||||
```
|
||||
|
||||
Once you've checked which dependencies are outdated, you can start updating them.
|
||||
|
||||
To update a single dependency, use the following:
|
||||
|
||||
```bash
|
||||
npm update package-name
|
||||
```
|
||||
|
||||
This updates the package only within the version range allowed by your `package.json` file. For example, to update Express, you can use the following:
|
||||
|
||||
```bash
|
||||
npm update express
|
||||
```
|
||||
|
||||
If you want to skip the version range and install the latest version of a package, use the following command:
|
||||
|
||||
```bash
|
||||
npm install package-name@latest
|
||||
```
|
||||
|
||||
To update all dependencies that fall within the allowed version ranges, run:
|
||||
|
||||
```bash
|
||||
npm update
|
||||
```
|
||||
|
||||
However, note that `npm update` does not upgrade a package to a new major version if your `package.json` doesn't allow it. Major versions often contain breaking changes, so npm won't apply them automatically.
|
||||
|
||||
If you specifically want the newest major version, you must run:
|
||||
|
||||
```bash
|
||||
npm install package-name@latest
|
||||
```
|
||||
|
||||
This forces npm to install the most recent release, no matter what version range is in your `package.json`.
|
||||
|
||||
# --questions--
|
||||
|
||||
## --text--
|
||||
|
||||
Which command correctly installs a specific version of an npm package?
|
||||
|
||||
## --answers--
|
||||
|
||||
`npm add package@version-number`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command you use to add packages and specify versions in Node.js.
|
||||
|
||||
---
|
||||
|
||||
`npm get package@version-number`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command you use to add packages and specify versions in Node.js.
|
||||
|
||||
---
|
||||
|
||||
`npm install package@version-number`
|
||||
|
||||
---
|
||||
|
||||
`npm use package@version-number`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command you use to add packages and specify versions in Node.js.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
|
||||
## --text--
|
||||
|
||||
Which command is used to check which dependencies are outdated in a Node.js project?
|
||||
|
||||
## --answers--
|
||||
|
||||
`npm check`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that specifically reports old package versions.
|
||||
|
||||
---
|
||||
|
||||
`npm outdated`
|
||||
|
||||
---
|
||||
|
||||
`npm update`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that specifically reports old package versions.
|
||||
|
||||
---
|
||||
|
||||
`npm list`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that specifically reports old package versions.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
2
|
||||
|
||||
## --text--
|
||||
|
||||
Which command always updates a dependency to its latest major version in Node.js?
|
||||
|
||||
## --answers--
|
||||
|
||||
`npm update package-name`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that installs always installs the latest version.
|
||||
|
||||
---
|
||||
|
||||
`npm upgrade package-name`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that installs always installs the latest version.
|
||||
|
||||
---
|
||||
|
||||
`npm refresh package-name`
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about the command that installs always installs the latest version.
|
||||
|
||||
---
|
||||
|
||||
`npm install package-name@latest`
|
||||
|
||||
## --video-solution--
|
||||
|
||||
4
|
||||
@@ -0,0 +1,261 @@
|
||||
---
|
||||
id: 695b93cb572125a6fb19f39e
|
||||
title: What Is the package-lock.json File?
|
||||
challengeType: 19
|
||||
dashedName: what-is-the-package-lock-json-file
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
When you install dependencies with npm, especially in an existing project, npm looks at your `package.json` file to see which packages your project needs.
|
||||
|
||||
Each dependency in `package.json` includes a version number like this:
|
||||
|
||||
```bash
|
||||
"lodash": "^4.17.21"
|
||||
```
|
||||
|
||||
As you learned earlier, the **caret (^)** allows npm to install newer minor and patch versions like `4.18.0` or `4.17.22`. This flexibility is helpful, but it can also lead to problems.
|
||||
|
||||
If two developers run `npm install` at different times, npm might install slightly different versions of the same package. Even small differences can cause bugs or unexpected behavior.
|
||||
|
||||
The `package-lock.json` file solves this. It is created automatically the first time you run `npm install`, and it locks in the exact versions of every dependency that was installed—including all child dependencies, which are dependencies of dependencies.
|
||||
|
||||
This guarantees that everyone working on the project gets the same versions of packages every time.
|
||||
|
||||
Here's a simple `package.json` file with `lodash` as a dependency:
|
||||
|
||||
```bash
|
||||
{
|
||||
"name": "package-lock-json",
|
||||
"version": "1.0.0",
|
||||
"description": "",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": [],
|
||||
"author": "",
|
||||
"license": "ISC",
|
||||
"type": "commonjs",
|
||||
"dependencies": {
|
||||
"lodash": "^4.17.21"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
And here is the matching section from the `package-lock.json`:
|
||||
|
||||
```bash
|
||||
"node_modules/lodash": {
|
||||
"version": "4.17.21",
|
||||
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
|
||||
"integrity": "sha512-v2kDEe57..."
|
||||
}
|
||||
```
|
||||
|
||||
Notice the difference:
|
||||
|
||||
* In `package.json`, `lodash` is listed as `^4.17.21` — a flexible rule.
|
||||
|
||||
* In `package-lock.json`, `lodash` is pinned to version `4.17.21`.
|
||||
|
||||
|
||||
No matter when someone runs `npm install`, they will get that exact version.
|
||||
|
||||
This way, no matter when someone runs `npm install`, they will get the exact same version of Lodash every time.
|
||||
|
||||
Note that this also applies to child dependencies, which are dependencies of any dependencies you use for your project.
|
||||
|
||||
For example, here's part of the `package-lock.json` file for a project using Express:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "package-lock-json-file",
|
||||
"version": "1.0.0",
|
||||
"lockfileVersion": 3,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"name": "package-lock-json-file",
|
||||
"version": "1.0.0",
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"express": "^5.2.1"
|
||||
}
|
||||
},
|
||||
...
|
||||
"node_modules/etag": {
|
||||
"version": "1.8.1",
|
||||
"resolved": "https://registry.npmjs.org/etag/-/etag-1.8.1.tgz",
|
||||
"integrity": "sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==",
|
||||
"license": "MIT",
|
||||
"engines": {
|
||||
"node": ">= 0.6"
|
||||
}
|
||||
},
|
||||
"node_modules/express": {
|
||||
"version": "5.2.1",
|
||||
"resolved": "https://registry.npmjs.org/express/-/express-5.2.1.tgz",
|
||||
"integrity": "sha512-hIS4idWWai69NezIdRt2xFVofaF4j+6INOpJlVOLDO8zXGpUVEVzIYk12UUi2JzjEzWL3IOAxcTubgz9Po0yXw==",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"accepts": "^2.0.0",
|
||||
"body-parser": "^2.2.1",
|
||||
"content-disposition": "^1.0.0",
|
||||
"content-type": "^1.0.5",
|
||||
"cookie": "^0.7.1",
|
||||
"cookie-signature": "^1.2.1",
|
||||
"debug": "^4.4.0",
|
||||
"depd": "^2.0.0",
|
||||
"encodeurl": "^2.0.0",
|
||||
"escape-html": "^1.0.3",
|
||||
"etag": "^1.8.1",
|
||||
"finalhandler": "^2.1.0",
|
||||
"fresh": "^2.0.0",
|
||||
"http-errors": "^2.0.0",
|
||||
"merge-descriptors": "^2.0.0",
|
||||
"mime-types": "^3.0.0",
|
||||
"on-finished": "^2.4.1",
|
||||
"once": "^1.4.0",
|
||||
"parseurl": "^1.3.3",
|
||||
"proxy-addr": "^2.0.7",
|
||||
"qs": "^6.14.0",
|
||||
"range-parser": "^1.2.1",
|
||||
"router": "^2.2.0",
|
||||
"send": "^1.1.0",
|
||||
"serve-static": "^2.2.0",
|
||||
"statuses": "^2.0.1",
|
||||
"type-is": "^2.0.1",
|
||||
"vary": "^1.1.2"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">= 18"
|
||||
},
|
||||
"funding": {
|
||||
"type": "opencollective",
|
||||
"url": "https://opencollective.com/express"
|
||||
}
|
||||
},
|
||||
...others
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
You can see that besides Express itself, there are other packages like `accepts`, `mime-types`, and `negotiator`. These are child dependencies, which are packages Express depends on internally to work.
|
||||
|
||||
Also notice that, while the `dependencies` in `node_modules/express` do use caret characters for ranges, but if you find the entry for each child dependency like `node_modules/etags`, they're pinned to a specific version.
|
||||
|
||||
In short, the `package-lock.json` file keeps everyone on the same page and ensures consistency across developer machines, CI servers, deployments, and other environments.
|
||||
|
||||
It is important to always commit your `package-lock.json` file with Git so your team shares the same setup. Also, do not edit the `package-lock.json` file manually—npm will update it automatically whenever dependencies change.
|
||||
|
||||
# --questions--
|
||||
|
||||
## --text--
|
||||
|
||||
How does the `package-lock.json` file solve version inconsistency issues between different environments?
|
||||
|
||||
## --answers--
|
||||
|
||||
By automatically updating all dependencies to their latest versions.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how it ensures everyone installs the same dependency versions.
|
||||
|
||||
---
|
||||
|
||||
By deleting old dependencies before installing new ones.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how it ensures everyone installs the same dependency versions.
|
||||
|
||||
---
|
||||
|
||||
By freezing the exact versions of dependencies that were installed.
|
||||
|
||||
---
|
||||
|
||||
By storing only the major version numbers of each dependency.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about how it ensures everyone installs the same dependency versions.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
|
||||
## --text--
|
||||
|
||||
Why should you always commit your `package-lock.json` file to Git?
|
||||
|
||||
## --answers--
|
||||
|
||||
To make npm run faster on your machine.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about keeping every developer's environment consistent.
|
||||
|
||||
---
|
||||
|
||||
To let your team share the same dependency versions and setup.
|
||||
|
||||
---
|
||||
|
||||
To automatically update outdated dependencies.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about keeping every developer's environment consistent.
|
||||
|
||||
---
|
||||
|
||||
To reduce the size of your Git repository.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about keeping every developer's environment consistent.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
2
|
||||
|
||||
## --text--
|
||||
|
||||
What are child dependencies?
|
||||
|
||||
## --answers--
|
||||
|
||||
Packages that are installed but never used in the project.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about dependencies that your main dependencies themselves depend on.
|
||||
|
||||
---
|
||||
|
||||
Packages that depend on your project's main files to run.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about dependencies that your main dependencies themselves depend on.
|
||||
|
||||
---
|
||||
|
||||
Packages that are only used during development.
|
||||
|
||||
### --feedback--
|
||||
|
||||
Think about dependencies that your main dependencies themselves depend on.
|
||||
|
||||
---
|
||||
|
||||
Packages that your dependencies rely on internally to work.
|
||||
|
||||
## --video-solution--
|
||||
|
||||
4
|
||||
36
curriculum/structure/blocks/lecture-introduction-to-npm.json
Normal file
36
curriculum/structure/blocks/lecture-introduction-to-npm.json
Normal file
@@ -0,0 +1,36 @@
|
||||
{
|
||||
"name": "Introduction to npm",
|
||||
"isUpcomingChange": true,
|
||||
"dashedName": "lecture-introduction-to-npm",
|
||||
"helpCategory": "Backend Development",
|
||||
"blockLayout": "challenge-list",
|
||||
"challengeOrder": [
|
||||
{ "id": "695b93b7d61d4520790c3903", "title": "What Is npm?" },
|
||||
{
|
||||
"id": "695b93cb572125a6fb19f399",
|
||||
"title": "What Is a package.json File?"
|
||||
},
|
||||
{
|
||||
"id": "695b93cb572125a6fb19f39a",
|
||||
"title": "What Are Package Dependencies and What Are Some Considerations for Choosing an External Package?"
|
||||
},
|
||||
{
|
||||
"id": "695b93cb572125a6fb19f39b",
|
||||
"title": "What Is Semantic Versioning?"
|
||||
},
|
||||
{
|
||||
"id": "695b93cb572125a6fb19f39c",
|
||||
"title": "How Can You Install and Remove Dependencies?"
|
||||
},
|
||||
{
|
||||
"id": "695b93cb572125a6fb19f39d",
|
||||
"title": "How Can You Install Specific Versions and Manage Dependencies?"
|
||||
},
|
||||
{
|
||||
"id": "695b93cb572125a6fb19f39e",
|
||||
"title": "What Is the package-lock.json File?"
|
||||
}
|
||||
],
|
||||
"blockLabel": "lecture",
|
||||
"usesMultifileEditor": true
|
||||
}
|
||||
@@ -21,7 +21,10 @@
|
||||
{
|
||||
"dashedName": "node-package-manager",
|
||||
"comingSoon": true,
|
||||
"blocks": ["lecture-working-with-npm-scripts"]
|
||||
"blocks": [
|
||||
"lecture-introduction-to-npm",
|
||||
"lecture-working-with-npm-scripts"
|
||||
]
|
||||
},
|
||||
{
|
||||
"dashedName": "http-and-the-web-standards-model",
|
||||
@@ -48,26 +51,14 @@
|
||||
"comingSoon": true,
|
||||
"blocks": []
|
||||
},
|
||||
{
|
||||
"dashedName": "websockets",
|
||||
"comingSoon": true,
|
||||
"blocks": []
|
||||
},
|
||||
{
|
||||
"dashedName": "node-and-sql",
|
||||
"comingSoon": true,
|
||||
"blocks": []
|
||||
},
|
||||
{ "dashedName": "websockets", "comingSoon": true, "blocks": [] },
|
||||
{ "dashedName": "node-and-sql", "comingSoon": true, "blocks": [] },
|
||||
{
|
||||
"dashedName": "security-and-privacy",
|
||||
"comingSoon": true,
|
||||
"blocks": []
|
||||
},
|
||||
{
|
||||
"dashedName": "authentication",
|
||||
"comingSoon": true,
|
||||
"blocks": []
|
||||
},
|
||||
{ "dashedName": "authentication", "comingSoon": true, "blocks": [] },
|
||||
{
|
||||
"dashedName": "tooling-and-deployment",
|
||||
"comingSoon": true,
|
||||
|
||||
Reference in New Issue
Block a user