如何将非Angular CLI创建的Angular应用迁移至CLI项目模式？

Hey there! Migrating a hand-built Angular app (without the CLI) to an Angular CLI project is a great move—you’ll unlock all the handy tools like ng serve, ng build, and automated schematics. Let’s break down the optimal, step-by-step approach to make this smooth:

First, make sure you create a CLI project that matches your existing Angular version—this avoids compatibility headaches.

• Check your current Angular version with:

  npm list @angular/core
  

• Create a new CLI project with that exact version (replace X.Y.Z with your version number):

  ng new my-migrated-app --version=X.Y.Z
  

• Add flags like --routing if your original app uses routing, and pick the same style preprocessor (CSS/SCSS/LESS) you were using before.

Now it’s time to move your actual app logic over:

• Copy all your components, services, directives, pipes, and custom modules from your old project’s source folder into the new project’s src/app directory. Keep the folder structure intact—if you had a src/app/shared folder in your old app, drop it right into the new src/app.
• Update your root module (usually app.module.ts) to import all your migrated components, services, and third-party modules just like you had in your old app. Don’t forget to declare components and provide services where needed!
• Copy over component templates (.html) and style files (.css/.scss) to their corresponding component folders in the CLI project. Double-check that relative paths in templates (like to other components or assets) are correct.

• Open your old project’s package.json and copy over all non-Angular core dependencies (things like UI libraries, lodash, extra RxJS operators, etc.) into the new project’s package.json. Then run npm install to install them.
• Migrate environment-specific settings: If you had different configs for dev/prod (like API endpoints), paste those into the new project’s src/environments/environment.ts (dev) and environment.prod.ts (prod).
• Tweak the angular.json file (CLI’s main config) to match your old setup:
  • Adjust architect/build/options/outputPath if your old app used a different build output directory than dist.
  • Add global styles or scripts (like Bootstrap or jQuery) to the styles and scripts arrays under architect/build/options if you were using them globally.
  • Set a custom port in architect/serve/options/port if you need ng serve to run on a specific port.

• Copy all your static files (images, fonts, JSON data, etc.) into the new project’s src/assets folder. If you had assets in other locations, you can add their paths to the assets array in angular.json so the CLI includes them during builds.

Fire up ng serve and work through any errors that pop up:

• Path errors: If templates can’t find assets or components, double-check relative paths. For example, if your old app used /images/logo.png, you might need to change that to ./assets/images/logo.png in the CLI project.
• Missing dependencies: If you see "module not found" errors, verify that you installed the required npm packages (e.g., if you used @angular/material, make sure it’s installed and imported in your modules).
• Strict mode errors: The CLI enables strict type-checking by default. If your old code isn’t strict-compliant, you can temporarily disable the strict flag in tsconfig.json and fix issues gradually later.

Once ng serve runs smoothly, take some time to optimize:

• Use CLI schematics (ng generate component, ng generate service) for future code additions—they handle module imports and file structure automatically.
• Set up lazy loading for routes if you haven’t already—the CLI makes this easy with built-in support.
• Ditch any old custom build configs (like a manual webpack.config.js) since the CLI handles most build needs out of the box.

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