Angular2spa bundling improvements #1360

New Issue

fergalmoran · 2025-08-09T17:19:51Z

fergalmoran commented

2025-08-09 17:19:51 +00:00

Originally created by @SteveSandersonMS on 9/28/2016

These are significant changes, so I'm calling them out as a pull request, (even though I'm just about to merge it). If you have feedback/questions/etc, please do post here even though it will probably be merged by the time you see this - we can still change things.

The main differences are:

We now select between 'dev' and 'prod' builds based on the presence of a --env.prod flag, and not based on the ASPNETCORE_ENVIRONMENT env var. This is much better, because it means build and publish scripts can reliably trigger the correct dev/prod build in a natural way. See how project.json's prepublish scripts can now easily guarantee the correct build format. Relying on the ASPNETCORE_ENVIRONMENT var before made no sense really, given that the current value just reflects what else you're doing on your machine, and you might not remember to change it before publishing your app.
- Calling the flag --env.prod is not arbitrary - this is the flag format that Webpack 2 uses, so when we later update to Webpack 2, people won't have to change their build scripts.
Server-side prerendering now uses a prebuilt bundle (ClientApp/dist/main-server.js) - it no longer compiles your TypeScript at runtime. This is a big improvement - it means that:
- App startup is much faster (no need to wait for an extra round of compilation)
- Deployment is much simpler (no need to deploy your .ts source code or take runtime dependencies on any part of Webpack - you just deploy the ClientApp/dist/main-server.js file that comes out of the build process)
- Deployed apps have fewer ways to fail (you can no longer have issues with TypeScript compilation in production, because that no longer happens on your prod servers)
- Compatiblity with obscure webpack plugins is now basically 100%, because we're no longer doing anything weird (previously we used aspnet-webpack's LoadViaWebpack feature to compile to an in-memory filesystem, and in some edge cases, this confused some webpack plugins, but now we're just running a plain regular Webpack build system at build time and putting the results on disk, just like every other Webpack build system out there).
- Developers will be more able to debug any issues they encounter in server-side prerendering, because the server-side builds are no longer created using a hidden webpack config, and the output is no longer hidden in an in-memory filesystem. Now it's just a regular webpack config you can see and edit yourself, and the files go onto disk where you can see them yourself. Any build errors will now happen at build-time, not run time. You can even execute the prerendering bundle directly under node.exe (completely independently of ASP.NET) if that helps you track down anything unexpected.

Soon I'll be applying the equivalent changes to all the other templates (React, etc.).

*Originally created by @SteveSandersonMS on 9/28/2016* These are significant changes, so I'm calling them out as a pull request, (even though I'm just about to merge it). If you have feedback/questions/etc, please do post here even though it will probably be merged by the time you see this - we can still change things. The main differences are: - **We now select between 'dev' and 'prod' builds based on the presence of a `--env.prod` flag, and _not_ based on the `ASPNETCORE_ENVIRONMENT` env var**. This is much better, because it means build and publish scripts can reliably trigger the correct dev/prod build in a natural way. See how `project.json`'s prepublish scripts can now easily guarantee the correct build format. Relying on the `ASPNETCORE_ENVIRONMENT` var before made no sense really, given that the current value just reflects what else you're doing on your machine, and you might not remember to change it before publishing your app. - Calling the flag `--env.prod` is not arbitrary - this is the flag format that Webpack 2 uses, so when we later update to Webpack 2, people won't have to change their build scripts. - **Server-side prerendering now uses a prebuilt bundle (ClientApp/dist/main-server.js) - it no longer compiles your TypeScript at runtime**. This is a big improvement - it means that: - App startup is much faster (no need to wait for an extra round of compilation) - Deployment is much simpler (no need to deploy your `.ts` source code or take runtime dependencies on any part of Webpack - you just deploy the `ClientApp/dist/main-server.js` file that comes out of the build process) - Deployed apps have fewer ways to fail (you can no longer have issues with TypeScript compilation in production, because that no longer happens on your prod servers) - Compatiblity with obscure webpack plugins is now basically 100%, because we're no longer doing anything weird (previously we used `aspnet-webpack`'s `LoadViaWebpack` feature to compile to an in-memory filesystem, and in some edge cases, this confused some webpack plugins, but now we're just running a plain regular Webpack build system at build time and putting the results on disk, just like every other Webpack build system out there). - Developers will be more able to debug any issues they encounter in server-side prerendering, because the server-side builds are no longer created using a hidden webpack config, and the output is no longer hidden in an in-memory filesystem. Now it's just a regular webpack config you can see and edit yourself, and the files go onto disk where you can see them yourself. Any build errors will now happen at build-time, not run time. You can even execute the prerendering bundle directly under `node.exe` (completely independently of ASP.NET) if that helps you track down anything unexpected. Soon I'll be applying the equivalent changes to all the other templates (React, etc.).

fergalmoran closed this issue

2025-08-09 17:19:51 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#1360