Angular 5大型应用项目结构与独立构建机制技术问询

Hey there! Since you're moving from Backbone+Webpack to Angular 5 and need a framework that supports pluggable modules, let's break down your two key questions with practical, actionable solutions.

1. Project Structure for Pluggable Modules #

You'll want a shell + feature modules + shared/core layers structure—this keeps your main app lightweight while letting each module operate independently. Here's how to lay it out:

Root Directory Layout #

src/
├── shell/                  # Main app shell (layout, routing hub, module loader)
│   ├── app.component.ts    # Root component (navbar, footer, main outlet)
│   ├── app-routing.module.ts # Root routing (maps to lazy-loaded modules)
│   └── app.module.ts       # Shell module (imports core/shared, bootstraps app)
├── features/               # Pluggable feature modules (each is self-contained)
│   ├── user-management/    # Example module 1
│   │   ├── user-management.module.ts
│   │   ├── user-management-routing.module.ts
│   │   ├── components/     # Module-specific components
│   │   ├── services/       # Module-only services (provided in module)
│   │   ├── models/         # Module data models
│   │   └── public-api.ts   # Exports public components/services for cross-module use
│   └── dashboard/          # Example module 2 (same structure as above)
├── shared/                 # Reusable components/directives/pipes (shared across modules)
│   ├── components/
│   ├── directives/
│   └── shared.module.ts
├── core/                   # Global services/guards/interceptors (singletons)
│   ├── auth.service.ts
│   ├── http-interceptor.ts
│   └── core.module.ts
├── assets/                 # Global static assets (images, fonts)
└── environments/           # Environment configs (dev/prod)

Key Principles for Pluggability #

• Isolate Feature Modules: Each module should have its own NgModule, routing, and internal dependencies. No hard-coded references to other feature modules—use dynamic loading instead.
• Public API Exports: Use public-api.ts in each feature module to expose only what's needed externally. This prevents tight coupling.
• Dynamic Module Loading: Use Angular 5's SystemJsNgModuleLoader or import() syntax (with Webpack support) to load modules on demand. This lets you add/remove modules without modifying the shell's code.

2. Build Mechanism for Independent Module Development & Deployment #

To let your team work across timezones on separate modules and deploy individual modules without rebuilding the entire app, you'll need a monorepo + independent module builds setup. Here's how to implement it:

Core Strategies #

• Monorepo with Package Isolation: Use a tool like Lerna (or Nx, which integrates smoothly with Angular) to manage your project as a monorepo. Each feature module is a standalone package with its own package.json, build scripts, and versioning.
• Per-Module Builds:
  • For each feature module, configure a separate Angular CLI project (add to angular.json with ng generate application user-management) or a custom Webpack config.
  • Build each module as a UMD or ES2015 bundle (use ng build --project user-management --prod --output-hashing none for clean, importable files). This outputs standalone JS/CSS/assets for the module.
• Independent Deployment:
  • Publish each module's build artifacts to an internal npm registry (or a static asset server). Team members can publish updates to their module without touching the main app.
  • The shell app loads modules dynamically from the registry/server—no need to rebuild the entire app when a module updates. Just update the module's version or load path in the shell's config.
• Local Development Workflow:
  • Each module can run its own dev server (ng serve --project user-management) for isolated testing.
  • The shell app can proxy requests to the module's dev server, so you can test integration without building the module.

Critical Build Config Tips #

• Shared Dependency Hoisting: Use Lerna's hoisting feature to avoid duplicate Angular core packages across modules. This keeps bundle sizes small.
• Module Registry: Maintain a global config (e.g., module-registry.json) in the shell that lists available modules, their load paths, and metadata. This makes adding/removing modules as simple as updating this file.
• Error Handling: Add fallback logic for failed module loads (e.g., show a "Module unavailable" message) to keep the shell stable if a module deployment fails.

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