如何使用 WSL2 和 Docker 提高 VSCode 中的 TypeScript/Node 性能？

Question

I'm using VSCode on Windows (v1.58.2), and the Remote WSL extension (v0.58.2).

I have Docker Desktop (3.5.2, engine: 20.10.7) configured with Linux containers using the WSL2 backend.

I'm running some (I would have expected) fairly small-scale containers using Node (for a React frontend and a NodeJS backend) and MySQL (directly from mysql:8.0.23).

My source code is in my WSL2 $HOME directory, and is mounted into the Docker containers using bind mounts, eg (from docker-compose.yml , in the parent directory of the react-frontend and node_server directories)

services:
  nodejs:
    build:
      context: node_server
      dockerfile: Dockerfile
      target: dev
    image: my-nodejs
    container_name: my-nodejs
    env_file: ./node_server/.env
    environment: 
      - MYSQL_HOST=db
      - NODE_PORT=12345
    ports:
      - "3005:12345"
    volumes:
      - ./node_server/src/:/usr/app/src
      - ./motorlogging.db:/usr/app/motorlogging.db
    networks:
      - app-network
    depends_on: 
      - db

  db:
    image: mysql:8.0.23
    container_name: my-mysql-db
    env_file: ./node_server/.env
    environment:
      - MYSQL_ROOT_PASSWORD=$MYSQL_PW
      - MYSQL_PASSWORD=$MYSQL_PW
      - MYSQL_DATABASE=$MYSQL_DB
    ports:
      - "3307:3306"
      - "33070:33060"
    networks:
      - app-network
    volumes:
    - dbdata:/var/lib/mysql
    - dbconfig:/etc/my.cnf
    - type: bind
      source: ./node_server/src/__test_setup__/
      target: /docker-entrypoint-initdb.d/
    # healthcheck:
    #   test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
    #   interval: 5s
    cap_add:
      - SYS_NICE
frontend:
    build:
      context: react_frontend
      dockerfile: Dockerfile
      target: dev
    image: my-frontend
    container_name: my-frontend
    ports:
      - "3000:3000"
    volumes:
      - ./react_frontend/src/:/usr/app/src
      - ./react_frontend/public/:/usr/app/public
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

volumes:
  dbdata:
  dbconfig:

The React frontend (built with Create-React-App) Dockerfile reads (with unused targets removed):

FROM node:14.17-buster-slim AS base
# Default to production
ENV NODE_ENV=production

RUN mkdir /usr/app && chown -R node:node /usr/app/
WORKDIR /usr/app

USER node
COPY --chown=node:node package.json package-lock.json ./
RUN npm ci && npm cache clean --force
COPY --chown=node:node tsconfig.json ./

FROM base AS dev
ENV NODE_ENV=development
RUN npm install --only=development
ENV PATH /usr/app/node_modules/.bin:$PATH
CMD ["npm", "start"]

This all 'works', but memory usage by Vmmem is high (reaching whatever limit I set in .wslconfig , presently 4GB, and on occasion crashing the WSL2 container.

Autocomplete prompts using TypeScript are pretty slow (~seconds) and sometimes the use of Prettier to autoformat can hang the setup for a few-10 seconds.

htop in the WSL2 container shows memory being primarily consumed by (with .../node in $HOME/.vscode-server/bin/some long hash-like string/node , and .../ implying the same directory)

.../node --max-old-space-size=3072 .../extensions/node_modules/typescript/lib/tsserver.js ...
.../node .../extensions/dbaeumer.vscode-eslint-2.1.23/server/out/eslintServer
other node js files, lesser impact

I imagine that developing React and Node applications using VSCode, WSL2 and Docker isn't an uncommon task, so where did I go wrong when setting this up to get such frustrating performance? Or do I really just need more (than 4GB allocated, also tested with eg 6, 8 GB) RAM?

Answer 1

I've tried loads of combinations of this. Even running VSCode.dev inside wsl and accessing it via the browser was one option, but it's all jumping through so many hoops.

VSCode dev containers is supposed to address this in general, but on Windows I've found the performance to be unusable.

I've settled on running VSCode and docker inside a Linux VM on Windows, and have a 96% time saving in things like running up a server and watching code for changes making this setup my preferred way now.

The standardisation of devcontainer.json, sharing between developers, and being able to use github codespaces if you're away from your normal dev machine make this whole setup a pleasure to use.

see https://stackoverflow.com/a/72787362/183005 for detailed timing comparison and setup details