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

Using pnpm

The approach of pnpm feels a bit like the original package resolution of npm. Here, each package is essentially isolated and puts its own dependencies into a local node_modules subfolder.

There is, however, one crucial difference: instead of having a hard copy of each dependency, the different dependencies are made available through symbolic links. The advantage of this approach is that every dependency only needs to be resolved once per system.

The other advantage is that for most packages everything is as it should be. There is nothing hiding behind an archive or via some custom mapping defined by a module that would run in the beginning. The whole package resolution just works. The exception to this rule is packages that use their path to find other packages or work against a root directory. Since the physical location of the packages is global, and therefore different from the project’s location, these approaches do not work with pnpm.

Installing packages...