ng serve confusing raw size?

[ScriptType]

Command

serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

I just saw that ng serve raw size seems to be wrong? In the past, I at least thought they were correct.(When we still used webpack)

We see a raw size of 20.22 KB for the main bundle and 33.24 KB for the polyfills. Let's see what the browser says.

Not even close.

Then I thought, okay, maybe these are estimates for when I eventually build the project. So let's build the project.

The main bundle is now 193 KB, but this time at least the 193 KB is correct. Interestingly, the polyfills have the exact same size in ng serve --configuration production as in ng build, at least in the console, but not in the browser.

Am i missing something? Am I not reading the numbers correct do they mean something different?
They are atleast confusing i would say.

Also just standard ng serve numbers are also not the same as in the browser?

EDIT:
Ok looks like vite is adding allways the sourcemaps inline in serve without it its 20.22kb,
And the main size is smaller in serve than in build because of the cached data created.

I was pretty confused by it and i can imagine many others are also confused by it especially the behavior atleast to my memory changed compared to webpack.

Would it maybe be possible to aknowledge all files in the console?

Minimal Reproduction

ng new testSize
cd testSize
ng serve --configuration production

Exception or Error

No response

Your Environment

Angular CLI: 17.3.7
Node: 20.12.2
Package Manager: npm 10.5.0
OS: darwin arm64

Angular: 17.3.8
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1703.7
@angular-devkit/build-angular   17.3.7
@angular-devkit/core            17.3.7
@angular-devkit/schematics      17.3.7
@angular/cli                    17.3.7
@schematics/angular             17.3.7
rxjs                            7.8.1
typescript                      5.4.5
zone.js                         0.14.5

Anything else relevant?

It´s an behavior of showing the raw size in the console for ng serve completly different when compared to webpack.
Webpack shows for example 318.85kb for the main.js and the browser loads exactly 318.85kb its intuitive and predictable,

If we compare it to the current esbuilder/vite solution which adds sourcemaps (Not Angulars fault) and uses the cache on the file system and than shows 20.22kb which is literally impossible and absolutely unintuitive.
It would even be better to show no number at this point as it literally can't be evaluated for anything and only will bring confusion to anyone when they compare ng serve with ng build and the ng serve looks smaller in the cli log

No response

[clydin]

Development servers can perform transformation of code at runtime (typically on request) to support development workflows such as HMR, dependency prebundling, debugging, etc. The downloaded size will not necessarily match the initial built size nor is it intended to do so within the development server. While it is possible to use a production configuration with the development server, the result will still be a development-oriented browser experience.

[ScriptType]

@clydin this is only partially correct i looked into it , the main.js is bigger because sourcemaps are inlined inside of it.
Without it its exactly 20.22kb, than is the question why is it smaller than build? The Reason is in serve it uses the angular cache, all in all its very confusing and should in someway be reflected in the console.

[clydin]

Yes, sourcemaps may be inlined during development. The Vite-based development server adds them when it transforms a file to aid in debugging. To support a faster edit/refresh cycle, it also prebundles dependencies which is both why the code size is smaller and primarily why the files are transformed.
This is working as intended as the primary goal of the development server is to support the edit/refresh cycle. File sizes during development workflows are intended to be representative only and may vary greatly from a production deployment. Using a production configuration with the development server is also typically not a recommended workflow as it can cause a significant negative effect on edit/refresh times.
A note could be added to the console output to mention potential browser differences in transfer size. However, the console size information is still useful especially for larger projects with defer block and router usage where code splitting is present. The sizes can provide a useful indicator of potential issues in these cases.

[ScriptType]

Its all true what you are saying.
Still it behaves completly different than webpack, infact that is the reason i wrote here :P, switched from Webpack to esbuilder using ng serve and saw my bundle size being only 1/5 of the previous shown bundle size than looking in the browser to get a whole different bundlesize, and seeing that it uses the angular cache which is definetly a good thing but very confusing especially when you just made the switch :P.

To make it more intuitive would be pretty easy simply show the cache in initial chunks and also show the raw size of the js with and without the sourcemaps. maybe like this 20.22kb(194kb).

Also it wasn't really documented that the interpreting of these numbers completly changes after switching to esbuild.

TLDR:
In Webpack you got what you saw ng serve vs ng build compare numbers be happy that numbers are smaller.
In esbuilder the numbers even presented in the completly same way are not compareable to webpack (smaller numbers are not really smaller), and the numbers are not compareable against each other ng serve vs ng build is simply confusing.