Book Image

Modern Frontend Development with Node.js

By : Florian Rappl
5 (1)
Book Image

Modern Frontend Development with Node.js

5 (1)
By: Florian Rappl

Overview of this book

Almost a decade after the release of Node.js, the tooling used by frontend developers is fully embracing this cross-platform JavaScript runtime, which is sadly often limited to server-side web development. This is where this Node.js book comes in, showing you what this popular runtime has to offer and how you can unlock its full potential to create frontend-focused web apps. You’ll begin by learning the basics and internals of Node.js, before discovering how to divide your code into modules and packages. Next, you’ll get to grips with the most popular package managers and their uses and find out how to use TypeScript and other JavaScript variants with Node.js. Knowing which tool to use when is crucial, so this book helps you understand all the available state-of-the-art tools in Node.js. You’ll interact with linters such as ESLint and formatters such as Prettier. As you advance, you’ll become well-versed with the Swiss Army Knife for frontend developers – the bundler. You’ll also explore various testing utilities, such as Jest, for code quality verification. Finally, you’ll be able to publish your code in reusable packages with ease. By the end of this web development book, you’ll have gained the knowledge to confidently choose the right code structure for your repositories with all that you’ve learned about monorepos.
Table of Contents (17 chapters)
1
Part 1: Node.js Fundamentals
5
Part 2: Tooling
10
Part 3: Advanced Topics

Selecting another npm registry via .npmrc

To configure the behavior of npm, a special file called .npmrc is used. We’ve already briefly touched on this file in Chapter 3, Choosing a Package Manager. This file can be used not only to determine the source of the packages but also to define where to publish to.

A simple modification might look as follows:

.npmrc

; Lines starting with a semicolon or
# with a hash symbol are comments
registry=https://mycustomregistry.example.org

This way, all installations and publish attempts will be performed at https://mycustomregistry.example.org instead of the official registry located at https://registry.npmjs.org.

Quite often, this extreme approach is unnecessary or even unwanted. Instead, you might only want to use another registry for a subset of the packages. In the most common case, the subset is already defined by a scope.

Let’s say the @foo scope that we used in the previous section with the @foo/bar package...