Containerizing Frontend Build Process with Docker: A Practical Guide

The author, a frontend engineer, shares a practical experience of moving the build workflow of frontend projects into Docker containers to solve environment‑sharing problems and recurring package‑manager errors.

1. Scenario

All frontend projects previously shared a single Jenkins build environment where global versions of node , npm , and pnpm caused version‑conflict and lockfile errors across different business lines.

Developers could switch node versions with nvm , but managing consistent pnpm versions and avoiding npm cache interference remained difficult.

2. Problems Identified

Problem 1: Incompatible pnpm7 / pnpm8 lockfiles leading to frequent ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE errors.

Problem 2: Corrupted npm cache causing build failures (e.g., npm ERR! Cannot read property 'pickAlgorithm' of null ).

3. Solution Design

Docker is used to provide isolated build environments:

Prepare base images such as node‑vx.x.x combined with specific pnpm versions (e.g., pnpm7 , pnpm8 ) so developers can select the same version they use locally.

Run builds inside containers to completely avoid the host’s npm cache, ensuring a clean environment for each build.

Additional considerations include potential use of an internal npm proxy (similar to cnpm ) to speed up package installation, though this is left for future articles.

4. Practical Implementation

4.1 Prepare Base Image

A simple Dockerfile is shown to create a node16 image with [email protected] and yarn installed:

# dockerfile

FROM node:16.20

MAINTAINER xxx

# Install pnpm and yarn
RUN npm install [email protected] -g && \
    npm install yarn -g

# npm config (example)
RUN npm config set @scope/xxx/xxx

Build the image with:

docker build -t base_node16:1.0.0 .

4.2 Create Build Script

The build commands are placed into a build.sh file using echo -e :

echo -e "#!/bin/sh
npm install
npm build:prod" > build.sh

4.3 Run Container and Execute Build

The Jenkins Execute shell step is replaced with a Docker run command that mounts the workspace, sets the working directory, and runs the script:

docker container run -v /workspace/xxx:/dockerPath --rm -w /dockerPath --name test base_node16:1.0.0 ./build.sh

Key flags:

-v : bind‑mount host path into the container.

--rm : automatically remove the container after the build.

-w : set the working directory inside the container.

--name : give the container a name for easier inspection.

5. Conclusion

By encapsulating the build process in Docker, the author achieves isolated, reproducible environments, eliminates version‑conflict and npm‑cache issues, and keeps the original Jenkins workflow unchanged. Future work will address package‑install speed and more advanced Docker image customization.