Angular与Express项目结构咨询：是否共用node_modules？

Hey there! Great question—this is something a lot of full-stack devs stumble on when setting up Angular/Express projects, so it’s totally worth sorting out upfront. Let’s break down the two approaches, their pros and cons, and what makes sense for your current structure.

1. 共用根目录 node_modules #

If you put a single node_modules at the project root (above your application and server folders) and manage all dependencies in a root package.json, here’s what you’ll get:

• Pros:
  • Saves disk space by avoiding duplicate installs of shared dependencies (like eslint, prettier, or cross-env).
  • Single source of truth for all project dependencies, which can simplify dependency management for small projects.
• Cons:
  • Version conflict risk: Angular and Express often rely on different versions of core tools (like webpack, babel, or even certain utility packages). Forcing them to share a single dependency pool can break one or both parts of your app—trust me, debugging "why won’t Angular build suddenly?" after updating an Express dependency is no fun.
  • Command path headaches: Angular’s CLI (ng commands) expects to be installed in the same directory as your Angular project, so running it from the root might require weird path workarounds.
  • Bloated deployments: If you ever need to deploy just the backend or just the frontend, you’ll end up packaging all dependencies from both sides, which adds unnecessary bulk.

2. 各自独立存放 node_modules #

This means adding a package.json and node_modules folder inside both application (for Angular) and server (for Express). This is the more common approach for full-stack Angular/Express setups, and for good reason:

• Pros:
  • No dependency conflicts: Each project gets its own isolated environment. Angular can use its required version of webpack, and Express can use whatever it needs—no overlap, no breakage.
  • Clear separation of concerns: Each package.json only lists dependencies relevant to that part of the app, making it easier to track what’s needed for frontend vs backend.
  • Clean deployments: When you package the Angular app for production, you only include its dependencies; same for the Express server. No extra baggage.
  • Intuitive command execution: Just cd into application and run ng serve, or cd into server and run node app.js—no path tricks required.
• Cons:
  • Minor disk space duplication: Shared tools (like linters) will be installed twice. But with modern disk sizes, this is rarely a meaningful issue.
  • Slightly more setup: You’ll need to initialize two package.json files instead of one, but that’s a one-time task.

针对你的项目结构的推荐 #

Given your setup (application for Angular, server for Express), I strongly recommend going with separate node_modules folders for each directory to avoid version conflicts and keep your project clean.

If you want to mitigate the minor duplication issue later on, you can use npm/yarn workspaces to optimize things. Here’s a quick setup for that:

1. Add a root package.json with:

{
  "name": "my-fullstack-app",
  "private": true,
  "workspaces": [
    "application",
    "server"
  ]
}

2. Delete any existing node_modules in the subfolders, then run npm install from the root.

Workspaces will install shared dependencies at the root and keep project-specific dependencies in each subfolder’s node_modules—giving you the best of both worlds: no conflicts, and minimal duplication.

At the end of the day, start simple with separate dependencies first. You can always add workspaces later if you need to optimize.

内容的提问来源于stack exchange，提问作者Brandon Aguilar