mirror of
https://github.com/freeCodeCamp/freeCodeCamp.git
synced 2026-05-28 18:26:54 +00:00
feat(curriculum): add npm challenges to cert (#56062)
Co-authored-by: Ilenia <26656284+ilenia-magoni@users.noreply.github.com>
This commit is contained in:
Jessica Wilkins
@@ -2229,7 +2229,13 @@
|
||||
"pfui": { "title": "367", "intro": [] },
|
||||
"qjov": { "title": "368", "intro": [] },
|
||||
"niie": { "title": "369", "intro": [] },
|
||||
"ttip": { "title": "370", "intro": [] },
|
||||
"workshop-npm-packages": {
|
||||
"title": "Managing Packages with npm",
|
||||
"intro": [
|
||||
"npm (Node Package Manager), is a command line tool to install, create, and share packages of JavaScript code written for Node.js. There are many open source packages available on npm, so before starting a project, take some time to explore so you don't end up recreating the wheel for things like working with dates or fetching data from an API.",
|
||||
"In this workshop, you'll learn the basics of using npm, including how to work with the <code>package.json</code> file and how to manage your installed dependencies."
|
||||
]
|
||||
},
|
||||
"hjku": { "title": "371", "intro": [] },
|
||||
"sykw": { "title": "372", "intro": [] },
|
||||
"zzhp": { "title": "373", "intro": [] },
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Introduction to the Managing Packages with npm
|
||||
block: workshop-npm-packages
|
||||
superBlock: front-end-development
|
||||
---
|
||||
|
||||
## Introduction to the Managing Packages with npm
|
||||
|
||||
This is a test for the new project-based curriculum.
|
||||
@@ -0,0 +1,53 @@
|
||||
{
|
||||
"name": "Managing Packages with npm",
|
||||
"blockType": "workshop",
|
||||
"isUpcomingChange": true,
|
||||
"usesMultifileEditor": false,
|
||||
"hasEditableBoundaries": false,
|
||||
"dashedName": "workshop-npm-packages",
|
||||
"order": 370,
|
||||
"superBlock": "front-end-development",
|
||||
"challengeOrder": [
|
||||
{
|
||||
"id": "587d7fb3367417b2b2512bfb",
|
||||
"title": "How to Use package.json, the Core of Any Node.js Project or npm Package"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb3367417b2b2512bfc",
|
||||
"title": "Add a Description to Your package.json"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb4367417b2b2512bfd",
|
||||
"title": "Add Keywords to Your package.json"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb4367417b2b2512bfe",
|
||||
"title": "Add a License to Your package.json"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb4367417b2b2512bff",
|
||||
"title": "Add a Version to Your package.json"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb4367417b2b2512c00",
|
||||
"title": "Expand Your Project with External Packages from npm"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb5367417b2b2512c01",
|
||||
"title": "Manage npm Dependencies By Understanding Semantic Versioning"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb5367417b2b2512c02",
|
||||
"title": "Use the Tilde-Character to Always Use the Latest Patch Version of a Dependency"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb5367417b2b2512c03",
|
||||
"title": "Use the Caret-Character to Use the Latest Minor Version of a Dependency"
|
||||
},
|
||||
{
|
||||
"id": "587d7fb5367417b2b2512c04",
|
||||
"title": "Remove a Package from Your Dependencies"
|
||||
}
|
||||
],
|
||||
"helpCategory": "Backend Development"
|
||||
}
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
id: 587d7fb3367417b2b2512bfb
|
||||
title: How to Use package.json, the Core of Any Node.js Project or npm Package
|
||||
challengeType: 2
|
||||
forumTopicId: 301528
|
||||
dashedName: how-to-use-package-json-the-core-of-any-node-js-project-or-npm-package
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Working on these challenges will involve you writing your code using one of the following methods:
|
||||
|
||||
- Clone <a href="https://github.com/freeCodeCamp/boilerplate-npm/" target="_blank" rel="noopener noreferrer nofollow">this GitHub repo</a> and complete these challenges locally.
|
||||
- Use <a href="https://gitpod.io/?autostart=true#https://github.com/freeCodeCamp/boilerplate-npm/" target="_blank" rel="noopener noreferrer nofollow">our Gitpod starter project</a> to complete these challenges.
|
||||
- Use a site builder of your choice to complete the project. Be sure to incorporate all the files from our GitHub repo.
|
||||
|
||||
The `package.json` file is the center of any Node.js project or npm package. It stores information about your project. It consists of a single JSON object where information is stored in key-value pairs. There are only two required fields; `name` and `version`, but it’s good practice to provide additional information.
|
||||
|
||||
You can create the `package.json` file from the terminal using the `npm init` command. This will run a guided setup. Using `npm init` with the `-y` flag will generate the file without having it ask any questions, `npm init -y`.
|
||||
|
||||
If you look at the file tree of your project, you will find the `package.json` file on the top level of the tree. This is the file that you will be improving in the next couple of challenges.
|
||||
|
||||
One of the most common pieces of information in this file is the `author` field. It specifies who created the project, and can consist of a string or an object with contact or other details. An object is recommended for bigger projects, but a simple string like the following example will do for this project.
|
||||
|
||||
```json
|
||||
"author": "Jane Doe",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Add your name as the `author` of the project in the `package.json` file.
|
||||
|
||||
**Note:** Remember that you’re writing JSON, so all field names must use double-quotes (") and be separated with a comma (,).
|
||||
|
||||
If you are using Gitpod, make sure the app is running and the preview window is open. Copy the preview window's URL and paste it into the Solution Link input below.
|
||||
|
||||
# --hints--
|
||||
|
||||
`package.json` should have a valid "author" key
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.author, '"author" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
id: 587d7fb3367417b2b2512bfc
|
||||
title: Add a Description to Your package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301522
|
||||
dashedName: add-a-description-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
The next part of a good package.json file is the `description` field; where a short, but informative description about your project belongs.
|
||||
|
||||
If some day you plan to publish a package to npm, this is the string that should sell your idea to the user when they decide whether to install your package or not. However, that’s not the only use case for the description, it’s a great way to summarize what a project does. It’s just as important in any Node.js project to help other developers, future maintainers or even your future self understand the project quickly.
|
||||
|
||||
Regardless of what you plan for your project, a description is definitely recommended. Here's an example:
|
||||
|
||||
```json
|
||||
"description": "A project that does something awesome",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Add a `description` to the package.json file of your project.
|
||||
|
||||
**Note:** Remember to use double-quotes for field-names (") and commas (,) to separate fields.
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json should have a valid "description" key
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.description, '"description" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512bfd
|
||||
title: Add Keywords to Your package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301526
|
||||
dashedName: add-keywords-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
The `keywords` field is where you can describe your project using related keywords. Here's an example:
|
||||
|
||||
```json
|
||||
"keywords": [ "descriptive", "related", "words" ],
|
||||
```
|
||||
|
||||
As you can see, this field is structured as an array of double-quoted strings.
|
||||
|
||||
# --instructions--
|
||||
|
||||
Add an array of suitable strings to the `keywords` field in the package.json file of your project.
|
||||
|
||||
One of the keywords should be "freecodecamp".
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json should have a valid "keywords" key
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.keywords, '"keywords" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
"keywords" field should be an Array
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.isArray(packJson.keywords, '"keywords" is not an array');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
"keywords" should include "freecodecamp"
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.include(
|
||||
packJson.keywords,
|
||||
'freecodecamp',
|
||||
'"keywords" does not include "freecodecamp"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512bfe
|
||||
title: Add a License to Your package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301523
|
||||
dashedName: add-a-license-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
The `license` field is where you inform users of what they are allowed to do with your project.
|
||||
|
||||
Some common licenses for open source projects include MIT and BSD. License information is not required, and copyright laws in most countries will give you ownership of what you create by default. However, it’s always a good practice to explicitly state what users can and can’t do. Here's an example of the license field:
|
||||
|
||||
```json
|
||||
"license": "MIT",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Fill the `license` field in the package.json file of your project as you find suitable.
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json should have a valid "license" key
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.license, '"license" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512bff
|
||||
title: Add a Version to Your package.json
|
||||
challengeType: 2
|
||||
forumTopicId: 301525
|
||||
dashedName: add-a-version-to-your-package-json
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
A `version` is one of the required fields of your package.json file. This field describes the current version of your project. Here's an example:
|
||||
|
||||
```json
|
||||
"version": "1.2.0",
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Add a `version` to the package.json file of your project.
|
||||
|
||||
# --hints--
|
||||
|
||||
package.json should have a valid "version" key
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert(packJson.version, '"version" is missing');
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
---
|
||||
id: 587d7fb4367417b2b2512c00
|
||||
title: Expand Your Project with External Packages from npm
|
||||
challengeType: 2
|
||||
forumTopicId: 301527
|
||||
dashedName: expand-your-project-with-external-packages-from-npm
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
One of the biggest reasons to use a package manager, is their powerful dependency management. Instead of manually having to make sure that you get all dependencies whenever you set up a project on a new computer, npm automatically installs everything for you. But how can npm know exactly what your project needs? Meet the `dependencies` section of your package.json file.
|
||||
|
||||
In this section, packages your project requires are stored using the following format:
|
||||
|
||||
```json
|
||||
"dependencies": {
|
||||
"package-name": "version",
|
||||
"express": "4.14.0"
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
Add version `1.1.0` of the `@freecodecamp/example` package to the `dependencies` field of your `package.json` file.
|
||||
|
||||
**Note:** `@freecodecamp/example` is a faux package used as a learning tool.
|
||||
|
||||
# --hints--
|
||||
|
||||
`"dependencies"` should include `"@freecodecamp/example"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'@freecodecamp/example',
|
||||
'"dependencies" does not include "@freecodecamp/example"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
`"@freecodecamp/example"` version should be `"1.1.0"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.match(
|
||||
packJson.dependencies["@freecodecamp/example"],
|
||||
/^[\^\~]?1\.1\.0/,
|
||||
'Wrong version of "@freecodecamp/example" installed. It should be 1.1.0'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c01
|
||||
title: Manage npm Dependencies By Understanding Semantic Versioning
|
||||
challengeType: 2
|
||||
forumTopicId: 301529
|
||||
dashedName: manage-npm-dependencies-by-understanding-semantic-versioning
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
`Versions` of the npm packages in the dependencies section of your package.json file follow what’s called Semantic Versioning (SemVer), an industry standard for software versioning aiming to make it easier to manage dependencies. Libraries, frameworks or other tools published on npm should use SemVer in order to clearly communicate what kind of changes projects can expect if they update.
|
||||
|
||||
Knowing SemVer can be useful when you develop software that uses external dependencies (which you almost always do). One day, your understanding of these numbers will save you from accidentally introducing breaking changes to your project without understanding why things that worked yesterday suddenly don’t work today. This is how Semantic Versioning works according to the official website:
|
||||
|
||||
```json
|
||||
"package": "MAJOR.MINOR.PATCH"
|
||||
```
|
||||
|
||||
The MAJOR version should increment when you make incompatible API changes. The MINOR version should increment when you add functionality in a backwards-compatible manner. The PATCH version should increment when you make backwards-compatible bug fixes. This means that PATCHes are bug fixes and MINORs add new features but neither of them break what worked before. Finally, MAJORs add changes that won’t work with earlier versions.
|
||||
|
||||
# --instructions--
|
||||
|
||||
In the dependencies section of your `package.json` file, change the version of `@freecodecamp/example` to match MAJOR version 1, MINOR version 2 and PATCH version 13
|
||||
|
||||
# --hints--
|
||||
|
||||
`"dependencies"` should include `"@freecodecamp/example"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'@freecodecamp/example',
|
||||
'"dependencies" does not include "@freecodecamp/example"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
`"@freecodecamp/example"` version should be `"1.2.13"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.equal(
|
||||
packJson.dependencies["@freecodecamp/example"],
|
||||
'1.2.13',
|
||||
'Wrong version of "@freecodecamp/example". It should be 1.2.13'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c02
|
||||
title: Use the Tilde-Character to Always Use the Latest Patch Version of a Dependency
|
||||
challengeType: 2
|
||||
forumTopicId: 301532
|
||||
dashedName: use-the-tilde-character-to-always-use-the-latest-patch-version-of-a-dependency
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
In the last challenge, you told npm to only include a specific version of a package. That’s a useful way to freeze your dependencies if you need to make sure that different parts of your project stay compatible with each other. But in most use cases, you don’t want to miss bug fixes since they often include important security patches and (hopefully) don’t break things in doing so.
|
||||
|
||||
To allow an npm dependency to update to the latest PATCH version, you can prefix the dependency’s version with the tilde (`~`) character. Here's an example of how to allow updates to any `1.3.x` version.
|
||||
|
||||
```json
|
||||
"package": "~1.3.8"
|
||||
```
|
||||
|
||||
# --instructions--
|
||||
|
||||
In the package.json file, your current rule for how npm may upgrade `@freecodecamp/example` is to use a specific version (`1.2.13`). But now, you want to allow the latest `1.2.x` version.
|
||||
|
||||
Use the tilde (`~`) character to prefix the version of `@freecodecamp/example` in your dependencies, and allow npm to update it to any new _patch_ release.
|
||||
|
||||
**Note:** The version numbers themselves should not be changed.
|
||||
|
||||
# --hints--
|
||||
|
||||
`"dependencies"` should include `"@freecodecamp/example"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'@freecodecamp/example',
|
||||
'"dependencies" does not include "@freecodecamp/example"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
`"@freecodecamp/example"` version should match `"~1.2.13"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.match(
|
||||
packJson.dependencies["@freecodecamp/example"],
|
||||
/^\~1\.2\.13/,
|
||||
'Wrong version of "@freecodecamp/example". It should be ~1.2.13'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c03
|
||||
title: Use the Caret-Character to Use the Latest Minor Version of a Dependency
|
||||
challengeType: 2
|
||||
forumTopicId: 301531
|
||||
dashedName: use-the-caret-character-to-use-the-latest-minor-version-of-a-dependency
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Similar to how the tilde we learned about in the last challenge allows npm to install the latest PATCH for a dependency, the caret (`^`) allows npm to install future updates as well. The difference is that the caret will allow both MINOR updates and PATCHes.
|
||||
|
||||
Your current version of `@freecodecamp/example` should be `~1.2.13` which allows npm to install to the latest `1.2.x` version. If you were to use the caret (^) as a version prefix instead, npm would be allowed to update to any `1.x.x` version.
|
||||
|
||||
```json
|
||||
"package": "^1.3.8"
|
||||
```
|
||||
|
||||
This would allow updates to any `1.x.x` version of the package.
|
||||
|
||||
# --instructions--
|
||||
|
||||
Use the caret (`^`) to prefix the version of `@freecodecamp/example` in your dependencies and allow npm to update it to any new MINOR release.
|
||||
|
||||
**Note:** The version numbers themselves should not be changed.
|
||||
|
||||
# --hints--
|
||||
|
||||
`"dependencies"` should include `"@freecodecamp/example"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.property(
|
||||
packJson.dependencies,
|
||||
'@freecodecamp/example',
|
||||
'"dependencies" does not include "@freecodecamp/example"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
`"@freecodecamp/example"` version should match `"^1.x.x"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.match(
|
||||
packJson.dependencies["@freecodecamp/example"],
|
||||
/^\^1\./,
|
||||
'Wrong version of "@freecodecamp/example". It should be ^1.2.13'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
id: 587d7fb5367417b2b2512c04
|
||||
title: Remove a Package from Your Dependencies
|
||||
challengeType: 2
|
||||
forumTopicId: 301530
|
||||
dashedName: remove-a-package-from-your-dependencies
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
You have now tested a few ways you can manage dependencies of your project by using the package.json's dependencies section. You have also included external packages by adding them to the file and even told npm what types of versions you want, by using special characters such as the tilde or the caret.
|
||||
|
||||
But what if you want to remove an external package that you no longer need? You might already have guessed it, just remove the corresponding key-value pair for that package from your dependencies.
|
||||
|
||||
This same method applies to removing other fields in your package.json as well.
|
||||
|
||||
# --instructions--
|
||||
|
||||
Remove the `@freecodecamp/example` package from your dependencies.
|
||||
|
||||
**Note:** Make sure you have the right amount of commas after removing it.
|
||||
|
||||
# --hints--
|
||||
|
||||
`"dependencies"` should not include `"@freecodecamp/example"`.
|
||||
|
||||
```js
|
||||
(getUserInput) =>
|
||||
$.get(getUserInput('url') + '/_api/package.json').then(
|
||||
(data) => {
|
||||
var packJson = JSON.parse(data);
|
||||
assert.notProperty(
|
||||
packJson.dependencies,
|
||||
'@freecodecamp/example',
|
||||
'"dependencies" still includes "@freecodecamp/example"'
|
||||
);
|
||||
},
|
||||
(xhr) => {
|
||||
throw new Error(xhr.responseText);
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user