For most existing Angular CLI applications, Angular recommends migrating from the deprecated webpack-based browser builder to the application builder. After updating to Angular 18 or later, run Angular’s migration schematic, then inspect the changes, build the app, and verify its runtime and deployment behavior. If you want a smaller configuration change and do not need the integrated SSR and prerendering pipeline, browser-esbuild is a compatibility alternative.
What changes when you migrate?
The new Angular application build system uses esbuild and modern ESM output. Angular CLI uses Vite in the development-server role to serve builds produced by that system; Vite is not the production application bundler described by this migration. Angular considers the new system stable and supported, while the webpack-based browser builder is deprecated. Existing projects can keep using the old builder temporarily or opt out during an update, but new Angular CLI applications use application by default. See Angular’s migration guide.
As an Amazon Associate I earn from qualifying purchases.
The builder determines what the CLI builds. @angular/build:application builds a client bundle and can also produce a Node server and prerendered routes. @angular-devkit/build-angular:browser-esbuild builds a client application with esbuild. @angular-devkit/build-angular:browser is the webpack client builder. Library builds serve a different purpose; changing an application builder is not the same as migrating a library build. Angular documents these roles in its build reference.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Choose a migration route
| Route | Best fit | What to expect |
|---|---|---|
application via schematic |
Most existing applications, especially those that benefit from an integrated SSR or prerendering pipeline. | Angular recommends this route generally. The schematic updates configuration and supported webpack-specific code or stylesheet usage; it may also change SSR configuration and package dependencies. Project-specific manual work can remain. |
browser-esbuild manually |
Client applications where keeping configuration and code changes small is the priority. | It is designed for compatibility with existing browser applications. In many cases, changing the builder field is the main required edit. |
application manually |
Projects whose maintainers want the integrated application pipeline but need to control the migration edits themselves. | Expect more manual configuration work, particularly for existing SSR projects. Application building integrates responsibilities previously handled by separate app-shell, prerender, server, and SSR development-server builders. |
Choose based on the trade-off between migration effort and compatibility surface on one side, and integrated application, SSR, and prerendering capabilities on the other. Angular’s migration guide describes the supported paths and their caveats.
#1 Best Overall
Prepare before changing the builder
- Check version compatibility. Identify the Angular version you are targeting and confirm its supported Node.js, TypeScript, and RxJS versions in Angular’s version compatibility table. Compatibility ranges differ by release, so use the row for your target version rather than copying values from another major version.
- Review the current Known Issues. In the migration guide, check for issues relevant to your custom builders, webpack configuration, stylesheet imports, loaders, SSR server code, workers, and side-effectful imports.
- Record project assumptions. Check
angular.json, package scripts, deployment configuration, custom webpack integrations, and any commands that assume a particular output directory or run separate SSR and prerender steps.
Run the recommended migration to application
After updating to Angular 18 or later, Angular documents this command for the schematic:
ng update @angular/cli --name use-application-builder
During an Angular 18 update, the CLI update flow asks whether to run the migration. It is optional; you can run it manually after the update instead. The schematic can adjust angular.json, update supported webpack-specific styles or code, handle relevant SSR builder changes, and may update a build-package dependency. Inspect its changes rather than treating a successful schematic run as proof that every project-specific integration is compatible.
Recommended Free Tools
Make builder and option changes manually when needed
Use browser-esbuild for the compatibility route
In the build target in angular.json, change the builder to @angular-devkit/build-angular:browser-esbuild. Then build the project and investigate warnings or errors. This route targets client applications and does not provide the application builder’s integrated SSR and prerendering pipeline.
Use application without the schematic
Set the build target to @angular-devkit/build-angular:application, or use the package-qualified @angular/build:application where appropriate for the project’s installed packages and CLI version. Check the builder schema for that version before editing options. Common option changes documented by Angular include:
- Rename
maintobrowser. - Change
polyfillsto an array. - Remove
buildOptimizer,resourcesOutputPath,vendorChunk, andcommonChunk. - Rename
ngswConfigPathtoserviceWorker.
For SSR projects, the application builder consolidates work previously split across separate builders. The migration may replace older @nguniversal usage and introduce @angular/ssr; inspect the resulting server entry points and configuration rather than assuming an existing SSR setup transfers unchanged.
Rank #3
Audit scripts, output paths, and development serving
The usual build command remains ng build, but check scripts for changed options and for separate SSR or prerender commands that may no longer be needed. A notable deployment difference is the application builder’s default output directory: dist/<project-name>/browser. If hosting, packaging, or CI scripts expect the old browser-builder output location, update them or set an appropriate output configuration.
ng serve continues to start the development server, and Angular CLI detects the build system automatically. Angular notes that stylesheet processing may cause a flash of unstyled content (FOUC) during startup. Stylesheet and component-template hot module replacement are supported; general JavaScript HMR is not currently supported by the described system.
Check compatibility issues that can affect builds
Custom webpack behavior and stylesheets
Search for custom builders, webpack plugins, and configuration that depends on webpack-specific behavior. The migration can adjust common stylesheet forms such as ~ or ^ in @import and url(), but that does not migrate custom integrations automatically.
SSR server code and ESM
Migrated SSR server code should be ESM-compatible. Review CommonJS patterns such as require, __filename, and __dirname. Angular says the migration merges server and application TypeScript configuration and enables esModuleInterop for Express imports; verify that your own server code and dependencies work with the resulting setup.
Imports and module semantics
esbuild can warn when code calls a namespace import as a function in a way that does not follow ESM semantics. Angular’s guide uses moment as an example; where appropriate, use a conforming default import and review the project’s esModuleInterop configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Workers and side effects
Angular’s guide says worker code is not currently type-checked and nested web workers are not processed. It also notes a reported bundler issue in which order-dependent side-effect imports shared by lazy modules can run out of order. Prefer localized side effects where possible and check the migration guide’s current Known Issues for the status relevant to your Angular version.
Tests, assets, and custom imports
The new application-builder features are incompatible with the Karma test builder by default in the documentation described by Angular. An application-builder mode is available as a developer-preview opt-in; check its status for your target Angular version before relying on it. Application-only features such as define and file-extension loader support can replace some custom bundler needs, but may require TypeScript declarations and have import constraints. Do not assume those options are available with browser-esbuild.
Development-server prebundling
Angular CLI enables dependency prebundling by default in the development server. If linked packages or loader behavior cause problems, Angular documents the prebundle.exclude setting for excluding dependencies. Disabling all prebundling is another possible troubleshooting step, but can increase rebuild times.
Quick Recap
Build and validate the migrated application
- Run
ng buildand read all warnings and errors; address incompatibilities before treating the migration as complete. - Run the project’s tests and development server, including SSR or prerender flows if the application uses them. Confirm the behavior against the project’s actual requirements.
- Inspect the generated files and verify that deployment scripts, hosting configuration, and CI artifacts point to the correct output directory.
- Test the deployed application and any routes or server behavior that matter to the project. A schematic or successful build cannot establish that every custom integration and deployment assumption works unchanged.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →
