update from sparkleup
This commit is contained in:
parent
13cb89d718
commit
da02927202
|
|
@ -0,0 +1,457 @@
|
||||||
|
<!doctype html>
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<title>Zk | ctm-399</title>
|
||||||
|
<link rel="stylesheet" type="text/css" href="/style.css" />
|
||||||
|
<meta name="viewport" content="width=device-width" />
|
||||||
|
<meta charset="utf-8" />
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<main>
|
||||||
|
<header>
|
||||||
|
<h1>Zk | ctm-399</h1>
|
||||||
|
</header>
|
||||||
|
<article class="content">
|
||||||
|
<h1 id="how-to-use-nodejs-modules-with-npm-and-packagejson">How To Use Node.js Modules with npm and package.json</h1>
|
||||||
|
<p><em>The author selected the <a href="https://www.brightfunds.org/funds/open-internet-free-speech">Open Internet/Free Speech Fund</a> to receive a donation as part of the <a href="https://do.co/w4do-cta">Write for DOnations</a> program.</em></p>
|
||||||
|
<h3 id="introduction">Introduction</h3>
|
||||||
|
<p>Because of such features as its speedy Input/Output (I/O) performance and its basis in the well-known JavaScript language, <a href="https://nodejs.org/en/">Node.js</a> has quickly become a popular runtime environment for back-end web development. But as interest grows, larger applications are built, and managing the complexity of the codebase and its dependencies becomes more difficult. Node.js organizes this complexity using <em>modules</em>, which are any single JavaScript files containing functions or objects that can be used by other programs or modules. A collection of one or more modules is commonly referred to as a <em>package</em>, and these packages are themselves organized by package managers. </p>
|
||||||
|
<p>The <a href="https://www.npmjs.com/">Node.js Package Manager (npm)</a> is the default and most popular package manager in the Node.js ecosystem, and is primarily used to install and manage external modules in a Node.js project. It is also commonly used to install a wide range of CLI tools and run project scripts. npm tracks the modules installed in a project with the <code>package.json</code> file, which resides in a project’s directory and contains:</p>
|
||||||
|
<ul>
|
||||||
|
<li>All the modules needed for a project and their installed versions</li>
|
||||||
|
<li>All the metadata for a project, such as the author, the license, etc.</li>
|
||||||
|
<li>Scripts that can be run to automate tasks within the project</li>
|
||||||
|
</ul>
|
||||||
|
<p>As you create more complex Node.js projects, managing your metadata and dependencies with the <code>package.json</code> file will provide you with more predictable builds, since all external dependencies are kept the same. The file will keep track of this information automatically; while you may change the file directly to update your project’s metadata, you will seldom need to interact with it directly to manage modules.</p>
|
||||||
|
<p>In this tutorial, you will manage packages with npm. The first step will be to create and understand the <code>package.json</code> file. You will then use it to keep track of all the modules you install in your project. Finally, you will list your package dependencies, update your packages, uninstall your packages, and perform an audit to find security flaws in your packages.</p>
|
||||||
|
<h2 id="prerequisites">Prerequisites</h2>
|
||||||
|
<p>To complete this tutorial, you will need:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Node.js installed on your development machine. This tutorial uses version 18.3.0. To install this on macOS, follow the steps in <a href="https://www.digitalocean.com/community/tutorials/how-to-install-node-js-and-create-a-local-development-environment-on-macos">How to Install Node.js and Create a Local Development Environment on macOS</a>; to install this on Ubuntu 20.04, follow the <strong>Installing Using a PPA</strong> or <strong>Installing using the Node Version Manager</strong> section of <a href="https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-ubuntu-20-04">How To Install Node.js on Ubuntu 20.04</a>. By having Node.js installed you will also have npm installed; this tutorial uses version 8.11.0.</li>
|
||||||
|
</ul>
|
||||||
|
<h2 id="step-1-creating-a-packagejson-file">Step 1 — Creating a <code>package.json</code> File</h2>
|
||||||
|
<p>We begin this tutorial by setting up the example project—a fictional Node.js <code>locator</code> module that gets the user’s IP address and returns the country of origin. You will not be coding the module in this tutorial. However, the packages you manage would be relevant if you were developing it. </p>
|
||||||
|
<p>First, you will create a <code>package.json</code> file to store useful metadata about the project and help you manage the project’s dependent Node.js modules. As the suffix suggests, this is a JSON (JavaScript Object Notation) file. JSON is a standard format used for sharing, based on <a href="https://www.digitalocean.com/community/tutorials/understanding-objects-in-javascript">JavaScript objects</a> and consisting of data stored as key-value pairs. If you would like to learn more about JSON, read our <a href="https://www.digitalocean.com/community/tutorials/an-introduction-to-json">Introduction to JSON</a> article.</p>
|
||||||
|
<p>Since a <code>package.json</code> file contains numerous properties, it can be cumbersome to create manually, without copy and pasting a template from somewhere else. To make things easier, npm provides the <code>init</code> command. This is an interactive command that asks you a series of questions and creates a <code>package.json</code> file based on your answers.</p>
|
||||||
|
<h3 id="using-the-init-command">Using the <code>init</code> Command</h3>
|
||||||
|
<p>First, set up a project so you can practice managing modules. In your shell, create a new folder called <code>locator</code>:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>mkdir <^>locator<^>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Then move into the new folder:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>cd <^>locator<^>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Now, initialize the interactive prompt by entering:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm init
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p><$>[note]
|
||||||
|
<strong>Note</strong>: If your code will use Git for version control, create the Git repository first and then run <code>npm init</code>. The command automatically understands that it is in a Git-enabled folder. If a Git remote is set, it automatically fills out the <code>repository</code>, <code>bugs</code>, and <code>homepage</code> fields for your <code>package.json</code> file. If you initialized the repo after creating the <code>package.json</code> file, you will have to add this information in yourself. For more on Git version control, see our <a href="https://www.digitalocean.com/community/tutorial_series/introduction-to-git-installation-usage-and-branches">Introduction to Git: Installation, Usage, and Branches</a> series.
|
||||||
|
<$></p>
|
||||||
|
<p>You will receive the following output:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">This utility will walk you through creating a package.json file.</span><span class="w"></span>
|
||||||
|
<span class="na">It only covers the most common items, and tries to guess sensible defaults.</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="na">See `npm help json` for definitive documentation on these fields</span><span class="w"></span>
|
||||||
|
<span class="na">and exactly what they do.</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="na">Use `npm install <pkg>` afterwards to install a package and</span><span class="w"></span>
|
||||||
|
<span class="na">save it as a dependency in the package.json file.</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="na">Press ^C at any time to quit.</span><span class="w"></span>
|
||||||
|
<span class="na">package name: (locator)</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You will first be prompted for the <code>name</code> of your new project. By default, the command assumes it’s the name of the folder you’re in. Default values for each property are shown in parentheses <code>()</code>. Since the default value for <code>name</code> will work for this tutorial, press <code>ENTER</code> to accept it.</p>
|
||||||
|
<p>The next value to enter is <code>version</code>. Along with the <code>name</code>, this field is required if your project will be shared with others in the npm package repository. </p>
|
||||||
|
<p><$>[note]
|
||||||
|
<strong>Note:</strong> Node.js packages are expected to follow the <a href="https://semver.org/">Semantic Versioning</a> (semver) guide. Therefore, the first number will be the <code>MAJOR</code> version number that only changes when the API changes. The second number will be the <code>MINOR</code> version that changes when features are added. The last number will be the <code>PATCH</code> version that changes when bugs are fixed.
|
||||||
|
<$></p>
|
||||||
|
<p>Press <code>ENTER</code> so the default version is accepted.</p>
|
||||||
|
<p>The next field is <code>description</code>—a useful string to explain what your Node.js module does. Our fictional <code>locator</code> project would get the user’s IP address and return the country of origin. A fitting <code>description</code> would be <code>Finds the country of origin of the incoming request</code>, so type in something like this and press <code>ENTER</code>. The <code>description</code> is very useful when people are searching for your module.</p>
|
||||||
|
<p>The following prompt will ask you for the <code>entry point</code>. If someone installs and <code>requires</code> your module, what you set in the <code>entry point</code> will be the first part of your program that is loaded. The value needs to be the relative location of a JavaScript file, and will be added to the <code>main</code> property of the <code>package.json</code>. Press <code>ENTER</code> to keep the default value.</p>
|
||||||
|
<p><$>[note]
|
||||||
|
<strong>Note</strong>: Most modules have an <code>index.js</code> file as the main point of entry. This is the default value for a <code>package.json</code>‘s <code>main</code> property, which is the point of entry for npm modules. If there is no <code>package.json</code>, Node.js will try to load <code>index.js</code> by default.
|
||||||
|
<$></p>
|
||||||
|
<p>Next, you’ll be asked for a <code>test command</code>, an executable script or command to run your project tests. In many popular Node.js modules, tests are written and executed with <a href="https://mochajs.org/">Mocha</a>, <a href="https://jestjs.io/">Jest</a>, <a href="https://jasmine.github.io/">Jasmine</a>, or other test frameworks. Since testing is beyond the scope of this article, leave this option empty for now, and press <code>ENTER</code> to move on.</p>
|
||||||
|
<p>The <code>init</code> command will then ask for the project’s <a href="https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-repositories">GitHub Repository</a>. You won’t use this in this example, so leave it empty as well.</p>
|
||||||
|
<p>After the repository prompt, the command asks for <code>keywords</code>. This property is an array of strings with useful terms that people can use to find your repository. It’s best to have a small set of words that are really relevant to your project, so that searching can be more targeted. List these keywords as a string with commas separating each value. For this sample project, type <code>ip,geo,country</code> at the prompt. The finished <code>package.json</code> will have three items in the array for <code>keywords</code>.</p>
|
||||||
|
<p>The next field in the prompt is <code>author</code>. This is useful for users of your module who want to get in contact with you. For example, if someone discovers an exploit in your module, they can use this to report the problem so that you can fix it. The <code>author</code> field is a string in the following format: <code>"<^>Name<^> \<<^>Email<^>\> (<^>Website<^>)"</code>. For example, <code>"Sammy \<sammy@your_domain\> (https://your_domain)"</code> is a valid author. The email and website data are optional—a valid author could just be a name. Add your contact details as an author and confirm with <code>ENTER</code>.</p>
|
||||||
|
<p>Finally, you’ll be prompted for the <code>license</code>. This determines the legal permissions and limitations users will have while using your module. Many Node.js modules are open source, so npm sets the default to <a href="https://www.npmjs.com/package/isc-license">ISC</a>.</p>
|
||||||
|
<p>At this point, you would review your licensing options and decide what’s best for your project. For more information on different types of open source licenses, see this <a href="https://opensource.org/licenses">license list from the Open Source Initiative</a>. If you do not want to provide a license for a private repository, you can type <code>UNLICENSED</code> at the prompt. For this sample, use the default ISC license, and press <code>ENTER</code> to finish this process.</p>
|
||||||
|
<p>The <code>init</code> command will now display the <code>package.json</code> file it’s going to create. It will look similar to this:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">About to write to /home/<^>sammy<^>/locator/package.json:</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="na">{</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"name": "locator",</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"version": "1.0.0",</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"description": "Finds the country of origin of the incoming request",</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"main": "index.js",</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"scripts": {</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"test": "echo \"Error: no test specified\" && exit 1"</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">},</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"keywords": [</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"ip",</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"geo",</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"country"</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">],</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"author": "<^>Sammy<^> <<^>sammy<^>@<^>your_domain<^>> (https://<^>your_domain<^>)",</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">"license": "ISC"</span><span class="w"></span>
|
||||||
|
<span class="na">}</span><span class="w"></span>
|
||||||
|
|
||||||
|
|
||||||
|
<span class="na">Is this OK? (yes)</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Once the information matches what you see here, press <code>ENTER</code> to complete this process and create the <code>package.json</code> file. With this file, you can keep a record of modules you install for your project.</p>
|
||||||
|
<p>Now that you have your <code>package.json</code> file, you can test out installing modules in the next step.</p>
|
||||||
|
<h2 id="step-2-installing-modules">Step 2 — Installing Modules</h2>
|
||||||
|
<p>It is common in software development to use external libraries to perform ancillary tasks in projects. This allows the developer to focus on the business logic and create the application more quickly and efficiently.</p>
|
||||||
|
<p>For example, if our sample <code>locator</code> module has to make an external API request to get geographical data, we could use an HTTP library to make that task easier. Since our main goal is to return pertinent geographical data to the user, we could install a package that makes HTTP requests easier for us instead of rewriting this code for ourselves, a task that is beyond the scope of our project.</p>
|
||||||
|
<p>Let’s run through this example. In your <code>locator</code> application, you will use the <a href="https://github.com/axios/axios">axios</a> library, which will help you make HTTP requests. Install it by entering the following in your shell:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm install axios --save
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You begin this command with <code>npm install</code>, which will install the package (for brevity you can use <code>npm i</code>). You then list the packages that you want installed, separated by a space. In this case, this is <code>axios</code>. Finally, you end the command with the optional <code>--save</code> parameter, which specifies that <code>axios</code> will be saved as a project dependency.</p>
|
||||||
|
<p>When the library is installed, you will see output similar to the following:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">...</span><span class="w"></span>
|
||||||
|
<span class="na">+ axios@0.19.0</span><span class="w"></span>
|
||||||
|
<span class="na">added 5 packages from 8 contributors and audited 5 packages in 0.764s</span><span class="w"></span>
|
||||||
|
<span class="na">found 0 vulnerabilities</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Now, open the <code>package.json</code> file, using a text editor of your choice. This tutorial will use <code>nano</code>:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>nano package.json
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You’ll see a new property, as highlighted in the following:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="p">[</span><span class="err">label</span><span class="w"> </span><span class="err">loca</span><span class="kc">t</span><span class="err">or/package.jso</span><span class="kc">n</span><span class="p">]</span><span class="w"></span>
|
||||||
|
<span class="p">{</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"name"</span><span class="p">:</span><span class="w"> </span><span class="s2">"locator"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"version"</span><span class="p">:</span><span class="w"> </span><span class="s2">"1.0.0"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"description"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Finds the country of origin of the incoming request"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"main"</span><span class="p">:</span><span class="w"> </span><span class="s2">"index.js"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"scripts"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"test"</span><span class="p">:</span><span class="w"> </span><span class="s2">"echo \"Error: no test specified\" && exit 1"</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="p">},</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"keywords"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="s2">"ip"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="s2">"geo"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="s2">"country"</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="p">],</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"author"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Sammy sammy@your_domain (https://your_domain)"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"license"</span><span class="p">:</span><span class="w"> </span><span class="s2">"ISC"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="err"><^></span><span class="nt">"dependencies"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="err"><^></span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="err"><^></span><span class="nt">"axios"</span><span class="p">:</span><span class="w"> </span><span class="s2">"^0.19.0"</span><span class="err"><^></span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="err"><^></span><span class="p">}</span><span class="err"><^></span><span class="w"></span>
|
||||||
|
<span class="p">}</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>The <code>--save</code> option told npm to update the <code>package.json</code> with the module and version that was just installed. This is great, as other developers working on your projects can easily see what external dependencies are needed.</p>
|
||||||
|
<p><$>[note]
|
||||||
|
<strong>Note</strong>: You may have noticed the <code>^</code> before the version number for the <code>axios</code> dependency. Recall that semantic versioning consists of three digits: <strong>MAJOR</strong>, <strong>MINOR</strong>, and <strong>PATCH</strong>. The <code>^</code> symbol signifies that any higher MINOR or PATCH version would satisfy this version constraint. If you see <code>~</code> at the beginning of a version number, then only higher PATCH versions satisfy the constraint.
|
||||||
|
<$></p>
|
||||||
|
<p>When you are finished reviewing <code>package.json</code>, exit the file.</p>
|
||||||
|
<h3 id="development-dependencies">Development Dependencies</h3>
|
||||||
|
<p>Packages that are used for the development of a project but not for building or running it in production are called <em>development dependencies</em>. They are not necessary for your module or application to work in production, but may be helpful while writing the code.</p>
|
||||||
|
<p>For example, it’s common for developers to use <a href="https://en.wikipedia.org/wiki/Lint_(software)"><em>code linters</em></a> to ensure their code follows best practices and to keep the style consistent. While this is useful for development, this only adds to the size of the distributable without providing a tangible benefit when deployed in production.</p>
|
||||||
|
<p>Install a linter as a development dependency for your project. Try this out in your shell:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="n">npm</span><span class="w"> </span><span class="n">i</span><span class="w"> </span><span class="n">eslint</span><span class="mf">@6.0.0</span><span class="w"> </span><span class="o">--</span><span class="n">save</span><span class="o">-</span><span class="n">dev</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>In this command, you used the <code>--save-dev</code> flag. This will save <code>eslint</code> as a dependency that is only needed for development. Notice also that you added <code>@6.0.0</code> to your dependency name. When modules are updated, they are tagged with a version. The <code>@</code> tells npm to look for a specific tag of the module you are installing. Without a specified tag, npm installs the latest tagged version. Open <code>package.json</code> again:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>nano package.json
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>This will show the following:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="p">[</span><span class="err">label</span><span class="w"> </span><span class="err">loca</span><span class="kc">t</span><span class="err">or/package.jso</span><span class="kc">n</span><span class="p">]</span><span class="w"></span>
|
||||||
|
<span class="p">{</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"name"</span><span class="p">:</span><span class="w"> </span><span class="s2">"locator"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"version"</span><span class="p">:</span><span class="w"> </span><span class="s2">"1.0.0"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"description"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Finds the country of origin of the incoming request"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"main"</span><span class="p">:</span><span class="w"> </span><span class="s2">"index.js"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"scripts"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"test"</span><span class="p">:</span><span class="w"> </span><span class="s2">"echo \"Error: no test specified\" && exit 1"</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="p">},</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"keywords"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="s2">"ip"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="s2">"geo"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="s2">"country"</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="p">],</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"author"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Sammy sammy@your_domain (https://your_domain)"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"license"</span><span class="p">:</span><span class="w"> </span><span class="s2">"ISC"</span><span class="p">,</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"dependencies"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="nt">"axios"</span><span class="p">:</span><span class="w"> </span><span class="s2">"^0.19.0"</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="p">},</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="err"><^></span><span class="nt">"devDependencies"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="err"><^></span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="err"><^></span><span class="nt">"eslint"</span><span class="p">:</span><span class="w"> </span><span class="s2">"^6.0.0"</span><span class="err"><^></span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="err"><^></span><span class="p">}</span><span class="err"><^></span><span class="w"></span>
|
||||||
|
<span class="p">}</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p><code>eslint</code> has been saved as a <code>devDependencies</code>, along with the version number you specified earlier. Exit <code>package.json</code>.</p>
|
||||||
|
<h3 id="automatically-generated-files-node_modules-and-package-lockjson">Automatically Generated Files: <code>node_modules</code> and <code>package-lock.json</code></h3>
|
||||||
|
<p>When you first install a package to a Node.js project, npm automatically creates the <code>node_modules</code> folder to store the modules needed for your project and the <code>package-lock.json</code> file that you examined earlier. </p>
|
||||||
|
<p>Confirm these are in your working directory. In your shell, type <code>ls</code> and press <code>ENTER</code>. You will observe the following output:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">node_modules package.json package-lock.json</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>The <code>node_modules</code> folder contains every installed dependency for your project. In most cases, you should <strong>not</strong> commit this folder into your version controlled repository. As you install more dependencies, the size of this folder will quickly grow. Furthermore, the <code>package-lock.json</code> file keeps a record of the exact versions installed in a more succinct way, so including <code>node_modules</code> is not necessary.</p>
|
||||||
|
<p>While the <code>package.json</code> file lists dependencies that tell us the suitable versions that should be installed for the project, the <code>package-lock.json</code> file keeps track of all changes in <code>package.json</code> or <code>node_modules</code> and tells us the exact version of the package installed. You usually commit this to your version controlled repository instead of <code>node_modules</code>, as it’s a cleaner representation of all your dependencies.</p>
|
||||||
|
<h3 id="installing-from-packagejson">Installing from package.json</h3>
|
||||||
|
<p>With your <code>package.json</code> and <code>package-lock.json</code> files, you can quickly set up the same project dependencies before you start development on a new project. To demonstrate this, move up a level in your directory tree and create a new folder named <code>cloned_locator</code> in the same directory level as <code>locator</code>:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>cd ..
|
||||||
|
mkdir cloned_locator
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Move into your new directory:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>cd cloned_locator
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Now copy the <code>package.json</code> and <code>package-lock.json</code> files from <code>locator</code> to <code>cloned_locator</code>:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>cp ../locator/package.json ../locator/package-lock.json .
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>To install the required modules for this project, type:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm i
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>npm will check for a <code>package-lock.json</code> file to install the modules. If no lock file is available, it would read from the <code>package.json</code> file to determine the installations. It is usually quicker to install from <code>package-lock.json</code>, since the lock file contains the exact version of modules and their dependencies, meaning npm does not have to spend time figuring out a suitable version to install.</p>
|
||||||
|
<p>When deploying to production, you may want to skip the development dependencies. Recall that development dependencies are stored in the <code>devDependencies</code> section of <code>package.json</code>, and have no impact on the running of your app. When installing modules as part of the CI/CD process to deploy your application, omit the dev dependencies by running:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm i --production
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>The <code>--production</code> flag ignores the <code>devDependencies</code> section during installation. For now, stick with your development build. </p>
|
||||||
|
<p>Before moving to the next section, return to the <code>locator</code> folder:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>cd ../locator
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<h3 id="global-installations">Global Installations</h3>
|
||||||
|
<p>So far, you have been installing npm modules for the <code>locator</code> project. npm also allows you to install packages <em>globally</em>. This means that the package is available to your user in the wider system, like any other shell command. This ability is useful for the many Node.js modules that are CLI tools.</p>
|
||||||
|
<p>For example, you may want to blog about the <code>locator</code> project that you’re currently working on. To do so, you can use a library like <a href="https://hexo.io">Hexo</a> to create and manage your static website blog. Install the Hexo CLI globally like this:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm i hexo-cli -g
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>To install a package globally, you append the <code>-g</code> flag to the command.</p>
|
||||||
|
<p><$>[note]
|
||||||
|
<strong>Note</strong>: If you get a permission error trying to install this package globally, your system may require super user privileges to run the command. Try again with <code>sudo npm i hexo-cli -g</code>.
|
||||||
|
<$></p>
|
||||||
|
<p>Test that the package was successfully installed by typing:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>hexo --version
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You will see output similar to:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">hexo-cli: 2.0.0</span><span class="w"></span>
|
||||||
|
<span class="na">os: Linux 4.15.0-64-generic linux x64</span><span class="w"></span>
|
||||||
|
<span class="na">http_parser: 2.7.1</span><span class="w"></span>
|
||||||
|
<span class="na">node: 10.14.0</span><span class="w"></span>
|
||||||
|
<span class="na">v8: 7.6.303.29-node.16</span><span class="w"></span>
|
||||||
|
<span class="na">uv: 1.31.0</span><span class="w"></span>
|
||||||
|
<span class="na">zlib: 1.2.11</span><span class="w"></span>
|
||||||
|
<span class="na">ares: 1.15.0</span><span class="w"></span>
|
||||||
|
<span class="na">modules: 72</span><span class="w"></span>
|
||||||
|
<span class="na">nghttp2: 1.39.2</span><span class="w"></span>
|
||||||
|
<span class="na">openssl: 1.1.1c</span><span class="w"></span>
|
||||||
|
<span class="na">brotli: 1.0.7</span><span class="w"></span>
|
||||||
|
<span class="na">napi: 4</span><span class="w"></span>
|
||||||
|
<span class="na">llhttp: 1.1.4</span><span class="w"></span>
|
||||||
|
<span class="na">icu: 64.2</span><span class="w"></span>
|
||||||
|
<span class="na">unicode: 12.1</span><span class="w"></span>
|
||||||
|
<span class="na">cldr: 35.1</span><span class="w"></span>
|
||||||
|
<span class="na">tz: 2019a</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>So far, you have learned how to install modules with npm. You can install packages to a project locally, either as a production or development dependency. You can also install packages based on pre-existing <code>package.json</code> or <code>package-lock.json</code> files, allowing you to develop with the same dependencies as your peers. Finally, you can use the <code>-g</code> flag to install packages globally, so you can access them regardless of whether you’re in a Node.js project or not. </p>
|
||||||
|
<p>Now that you can install modules, in the next section you will practice techniques to administer your dependencies.</p>
|
||||||
|
<h2 id="step-3-managing-modules">Step 3 — Managing Modules</h2>
|
||||||
|
<p>A complete package manager can do a lot more than install modules. npm has over 20 commands relating to dependency management available. In this step, you will: </p>
|
||||||
|
<ul>
|
||||||
|
<li>List modules you have installed.</li>
|
||||||
|
<li>Update modules to a more recent version.</li>
|
||||||
|
<li>Uninstall modules you no longer need.</li>
|
||||||
|
<li>Perform a security audit on your modules to find and fix security flaws.</li>
|
||||||
|
</ul>
|
||||||
|
<p>While these examples will be done in your <code>locator</code> folder, all of these commands can be run globally by appending the <code>-g</code> flag at the end of them, exactly like you did when installing globally.</p>
|
||||||
|
<h3 id="listing-modules">Listing Modules</h3>
|
||||||
|
<p>If you would like to know which modules are installed in a project, it would be easier to use the <code>list</code> or <code>ls</code> command instead of reading the <code>package.json</code> directly. To do this, enter:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm ls
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You will see output like this:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">├─┬ axios@0.19.0</span><span class="w"></span>
|
||||||
|
<span class="na">│ ├─┬ follow-redirects@1.5.10</span><span class="w"></span>
|
||||||
|
<span class="na">│ │ └─┬ debug@3.1.0</span><span class="w"></span>
|
||||||
|
<span class="na">│ │ └── ms@2.0.0</span><span class="w"></span>
|
||||||
|
<span class="na">│ └── is-buffer@2.0.3</span><span class="w"></span>
|
||||||
|
<span class="na">└─┬ eslint@6.0.0</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">├─┬ @babel/code-frame@7.5.5</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ └─┬ @babel/highlight@7.5.0</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ ├── chalk@2.4.2 deduped</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ ├── esutils@2.0.3 deduped</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ └── js-tokens@4.0.0</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">├─┬ ajv@6.10.2</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ ├── fast-deep-equal@2.0.1</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ ├── fast-json-stable-stringify@2.0.0</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ ├── json-schema-traverse@0.4.1</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">│ └─┬ uri-js@4.2.2</span><span class="w"></span>
|
||||||
|
<span class="na">...</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>By default, <code>ls</code> shows the entire dependency tree—the modules your project depends on and the modules that your dependencies depend on. This can be a bit unwieldy if you want a high-level overview of what’s installed.</p>
|
||||||
|
<p>To only print the modules you installed without their dependencies, enter the following in your shell:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm ls --depth 0
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Your output will be:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">├── axios@0.19.0</span><span class="w"></span>
|
||||||
|
<span class="na">└── eslint@6.0.0</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>The <code>--depth</code> option allows you to specify what level of the dependency tree you want to see. When it’s <code>0</code>, you only see your top level dependencies.</p>
|
||||||
|
<h3 id="updating-modules">Updating Modules</h3>
|
||||||
|
<p>It is a good practice to keep your npm modules up to date. This improves your likelihood of getting the latest security fixes for a module. Use the <code>outdated</code> command to check if any modules can be updated:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm outdated
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You will get output like the following: </p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">Package Current Wanted Latest Location</span><span class="w"></span>
|
||||||
|
<span class="na">eslint 6.0.0 <^>6.7.1<^> <^>6.7.1<^> locator</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>This command first lists the <code>Package</code> that’s installed and the <code>Current</code> version. The <code>Wanted</code> column shows which version satisfies your version requirement in <code>package.json</code>. The <code>Latest</code> column shows the most recent version of the module that was published.</p>
|
||||||
|
<p>The <code>Location</code> column states where in the dependency tree the package is located. The <code>outdated</code> command has the <code>--depth</code> flag like <code>ls</code>. By default, the depth is 0.</p>
|
||||||
|
<p>It seems that you can update <code>eslint</code> to a more recent version. Use the <code>update</code> or <code>up</code> command like this:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm up eslint
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>The output of the command will contain the version installed:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">npm WARN locator@1.0.0 No repository field.</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="na">+ eslint@<^>6.7.1<^></span><span class="w"></span>
|
||||||
|
<span class="na">added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s</span><span class="w"></span>
|
||||||
|
<span class="na">found 0 vulnerabilities</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>If you wanted to update all modules at once, then you would enter:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm up
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<h3 id="uninstalling-modules">Uninstalling Modules</h3>
|
||||||
|
<p>The npm <code>uninstall</code> command can remove modules from your projects. This means the module will no longer be installed in the <code>node_modules</code> folder, nor will it be seen in your <code>package.json</code> and <code>package-lock.json</code> files. </p>
|
||||||
|
<p>Removing dependencies from a project is a normal activity in the software development lifecycle. A dependency may not solve the problem as advertised, or may not provide a satisfactory development experience. In these cases, it may better to uninstall the dependency and build your own module.</p>
|
||||||
|
<p>Imagine that <code>axios</code> does not provide the development experience you would have liked for making HTTP requests. Uninstall <code>axios</code> with the <code>uninstall</code> or <code>un</code> command by entering:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm un axios
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Your output will be similar to:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">npm WARN locator@1.0.0 No repository field.</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="na">removed 5 packages and audited 176 packages in 1.488s</span><span class="w"></span>
|
||||||
|
<span class="na">found 0 vulnerabilities</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>It doesn’t explicitly say that <code>axios</code> was removed. To verify that it was uninstalled, list the dependencies once again:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm ls --depth 0
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>Now, we only see that <code>eslint</code> is installed:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">└── eslint@<^>6.7.1<^></span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>This shows that you have successfully uninstalled the <code>axios</code> package.</p>
|
||||||
|
<h3 id="auditing-modules">Auditing Modules</h3>
|
||||||
|
<p>npm provides an <code>audit</code> command to highlight potential security risks in your dependencies. To see the audit in action, install an outdated version of the <a href="https://github.com/request/request">request</a> module by running the following:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="n">npm</span><span class="w"> </span><span class="n">i</span><span class="w"> </span><span class="n">request</span><span class="mf">@2.60.0</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>When you install this outdated version of <code>request</code>, you’ll notice output similar to the following:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">+ request@2.60.0</span><span class="w"></span>
|
||||||
|
<span class="na">added 54 packages from 49 contributors and audited 243 packages in 7.26s</span><span class="w"></span>
|
||||||
|
<span class="na">found 6 moderate severity vulnerabilities</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">run `npm audit fix` to fix them, or `npm audit` for details</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>npm is telling you that you have vulnerabilities in your dependencies. To get more details, audit your entire project with:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm audit
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>The <code>audit</code> command shows tables of output highlighting security flaws:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="o">=</span><span class="s">== npm audit security report ===</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="c1"># Run npm install request@2.88.0 to resolve 1 vulnerability</span><span class="w"></span>
|
||||||
|
<span class="na">┌───────────────┬──────────────────────────────────────────────────────────────┐</span><span class="w"></span>
|
||||||
|
<span class="na">│ Moderate │ Memory Exposure │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ Package │ tunnel-agent │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ Dependency of │ request │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ Path │ request > tunnel-agent │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ More info │ https://npmjs.com/advisories/598 │</span><span class="w"></span>
|
||||||
|
<span class="na">└───────────────┴──────────────────────────────────────────────────────────────┘</span><span class="w"></span>
|
||||||
|
|
||||||
|
<span class="c1"># Run npm update request --depth 1 to resolve 1 vulnerability</span><span class="w"></span>
|
||||||
|
<span class="na">┌───────────────┬──────────────────────────────────────────────────────────────┐</span><span class="w"></span>
|
||||||
|
<span class="na">│ Moderate │ Remote Memory Exposure │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ Package │ request │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ Dependency of │ request │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ Path │ request │</span><span class="w"></span>
|
||||||
|
<span class="na">├───────────────┼──────────────────────────────────────────────────────────────┤</span><span class="w"></span>
|
||||||
|
<span class="na">│ More info │ https://npmjs.com/advisories/309 │</span><span class="w"></span>
|
||||||
|
<span class="na">└───────────────┴──────────────────────────────────────────────────────────────┘</span><span class="w"></span>
|
||||||
|
<span class="na">...</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You can see the path of the vulnerability, and sometimes npm offers ways for you to fix it. You can run the update command as suggested, or you can run the <code>fix</code> subcommand of <code>audit</code>. In your shell, enter:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm audit fix
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>You will see similar output to:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code><span class="k">[secondary_label Output]</span><span class="w"></span>
|
||||||
|
<span class="na">+ request@2.88.0</span><span class="w"></span>
|
||||||
|
<span class="na">added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s</span><span class="w"></span>
|
||||||
|
<span class="na">fixed 2 of 6 vulnerabilities in 243 scanned packages</span><span class="w"></span>
|
||||||
|
<span class="w"> </span><span class="na">4 vulnerabilities required manual review and could not be updated</span><span class="w"></span>
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>npm was able to safely update two of the packages, decreasing your vulnerabilities by the same amount. However, you still have four vulnerabilities in your dependencies. The <code>audit fix</code> command does not always fix every problem. Although a version of a module may have a security vulnerability, if you update it to a version with a different API then it could break code higher up in the dependency tree.</p>
|
||||||
|
<p>You can use the <code>--force</code> parameter to ensure the vulnerabilities are gone, like this:</p>
|
||||||
|
<div class="codehilite"><pre><span></span><code>npm audit fix --force
|
||||||
|
</code></pre></div>
|
||||||
|
|
||||||
|
<p>As mentioned before, this is not recommended unless you are sure that it won’t break functionality.</p>
|
||||||
|
<h2 id="conclusion">Conclusion</h2>
|
||||||
|
<p>In this tutorial, you went through various exercises to demonstrate how Node.js modules are organized into packages, and how these packages are managed by npm. In a Node.js project, you used npm packages as dependencies by creating and maintaining a <code>package.json</code> file—a record of your project’s metadata, including what modules you installed. You also used the npm CLI tool to install, update, and remove modules, in addition to listing the dependency tree for your projects and checking and updating modules that are outdated.</p>
|
||||||
|
<p>In the future, leveraging existing code by using modules will speed up development time, as you don’t have to repeat functionality. You will also be able to create your own npm modules, and these will in turn will be managed by others via npm commands. As for next steps, experiment with what you learned in this tutorial by installing and testing the variety of packages out there. See what the ecosystem provides to make problem solving easier. For example, you could try out <a href="https://www.typescriptlang.org/">TypeScript</a>, a superset of JavaScript, or turn your website into mobile apps with <a href="https://cordova.apache.org/">Cordova</a>. If you’d like to learn more about Node.js, see our <a href="https://www.digitalocean.com/community/tags/node-js?type=tutorials">other Node.js tutorials</a>.</p>
|
||||||
|
</article>
|
||||||
|
<footer>
|
||||||
|
<p>Page generated on 2022-06-08</p>
|
||||||
|
</footer>
|
||||||
|
</main>
|
||||||
|
<script type="text/javascript">
|
||||||
|
document.querySelectorAll('.tag').forEach(tag => {
|
||||||
|
let text = tag.innerText;
|
||||||
|
tag.innerText = '';
|
||||||
|
tag.innerHTML = `<a href="/tags.html#${text}">${text}</a>`;
|
||||||
|
});
|
||||||
|
</script>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
Loading…
Reference in New Issue