Add build output result summary

[Valerioageno]

When a tuono build finish, the user doesn't know what is the size of the emitted JS chunks.
We should create an output message with the least of the routes chunk (that are lazy loaded by default).

Need inspiration from tanstack-start, nextJs, Remix build output

[HabeebullahOpe]

I'd be happy to work on the "add build output" feature. To clarify, the goal is to generate an output message upon completion of a Tuono build that displays the sizes of the emitted JavaScript chunks for each route, particularly those that are lazy-loaded by default.

Key.

• Creating a clear and concise output message that lists these sizes by route.
• Modifying the build process to capture the sizes of the emitted JS chunks.

[HabeebullahOpe]

If anyone has any additional suggestions or specific requirements for this feature, please let me know. Looking forward to feedback.

[Valerioageno]

Yes! Consider that all the routes are always lazy-loaded.

IMHO we should list all the routes + all the layout.tsx that apply for a specific set of routes.

Could you please propose an output shape before proceed with the implementation? We could take inspiration from other JS frameworks

[HabeebullahOpe]

If the last output from the build is something like:

Build Complete!

then output format should be something like this:

Build Complete!

Lazy-Loaded Route Chunk Sizes:

1. Route: /home

   • Layout: /layouts/main
   • JS Chunk: 45 KB

2. Route: /about

   • Layout: /layouts/about
   • JS Chunk: 30 KB

3. Route: /profile

   • Layout: /layouts/user
   • JS Chunk: 50 KB

4. Route: /dashboard

   • Layout: /layouts/admin
   • JS Chunk: 55 KB

Total Build Size: 180 KB

This format is clear and organized which makes it easy for users to understand the size distribution of the Js chunks for each route.

[HabeebullahOpe]

The Explanation of Benefits:

1. Numbering: Each route is listed with a number for clarity.
2. Route: Displays the route path.
3. Layout: Specifies the path of the layout file associated with the route.
4. JS Chunk: Shows the size of the emitted JavaScript chunk for that route.
5. Total Build Size: Summarizes the total size of all emitted chunks.

This should help

[Valerioageno]

I'm not a huge fan of such verbosity!
What about a file system view as next.js?

[Valerioageno]

Of course I would not include api/ folder in our build

[HabeebullahOpe]

Oh! ....maybe this would do

Build Complete!

JavaScript Chunk Sizes:

Route/Component Size

---

/home 45 KB
/about 30 KB
/profile 50 KB
/dashboard 55 KB

First Load JS shared by all:

• common.js 60 KB
• vendor.js 80 KB

Total Build Size: 320 KB

Would have love to include a file system view but that would require a build to show that

[HabeebullahOpe]

Designing a clearer view on canvas, if you could wait a bit

[HabeebullahOpe]

[marcalexiei]

Your last proposal looks fine to me!

Just a few notes:

1. "Route/Component" seems ambiguous:
   Most users will have a components folder as a sibling to the routes folder, which could cause confusion.
   I recommend using "Route" or "Route (Pages)" instead for clarity.
2. I would suggest change "Total Build Size" to something shorter, like"Bundle size" for simplicity.
3. We might also want to add the gzip size next to each size.
   Since servers typically transfer files to the browser using gzip compression,
   it could be helpful information to include in the output.

[HabeebullahOpe]

Alright, glad you like the last proposal, will work on the feedback and get to you shortly :)

[Valerioageno]

I'm not sure about the "total size". What would be the value given to the developer knowing the total across routes?

I think the Next.js solution is the best now since we can also split preloaded and server side rendered routes.

---

What is the difference between vendor and common?

[Valerioageno]

I like also using the ASCII characters to draw the file system. I think it is quite handy

[HabeebullahOpe]

Hi Valerio, thanks for the feedback! here are my thoughts on the points you have raised

-For the total size, that can be removed if it doesn't provide significant value to the developers, but I actually think it's necessary.

• While for the Vendor.js and Common.js, common.js is just common codes shared across multiple routes and the Vendor.js contains third party libraries and dependencies used in the projects.
• I will try and make the next.js solution effective in splitting preloaded and server-side rendered routes.

[jacobhq]

I think file size can be useful, but the most useful thing from the nextjs one is the first load JS, as well as the JS we actually send to the client for each route.

I do like the total build size, although make that clear if it's only the size of the client build. I may be wrong, but I think there is a lot of server stuff in target/release, and of course all the built dependencies!

ASCII tree is cool, and definitely useful in large projects, but not a deal-breaker if we don't implement it yet.

Also should serverside (.rs) routes be included in this?

[Valerioageno]

So if I understand correctly:

1. vendor is basically layout
2. common is just third party libraries

For the layout they get directly displayed in the listing (so not sure if that is necessary) while common would be something that could be read from a bundle analyzer.

The point I'm doing is: I wouldn't overcomplicate the implementation with something that is not strictly necessary for the development.

For @jacobhq points:

1. Agree on the first load JS and the separate bundles for each route
2. I still don't understand what would be the point of having the full JS size since we are splitting the bundles (open for understanding)
3. Indeed, not fundamental, but I'd try to write the features right first time with the best quality. When we have a clear vision on our needs and the time effort required we can definitely think to reduce the effort.
4. I wouldn't write anything about the server side since it's size does not have any impact on performance

[HabeebullahOpe]

Hey Jacob, thanks for your input! here are my thoughts

1. First Load JS and Client-sent JS will focus the output on these to provide more relevant info to developers.
2. The Total Build Size will just be kept clear for clients build alone
3. And as for the ASCII Tree, this should be an optional feature for large projects only.

I never thought about the server.rs part I don't really think these is necessary but if you have an alternate idea you could share, if these should be included. Thank you!

[HabeebullahOpe]

[HabeebullahOpe]

Hey Valerio, for clarifications and if I understand correctly, vendor is essentially the layout, while common represents third-party libraries. Layouts are directly displayed in the listing, so their necessity in the output can be reconsidered, whereas common libraries can be analyzed through a bundle analyzer.

To avoid overcomplicating the implementation, I'll focus on what's strictly necessary for development. The goal is to provide clear and relevant information without adding unnecessary complexity.

[jacobhq]

Agree! Let's see what Valerio thinks about the ASCII tree. Other than that, everything looks great :)

[HabeebullahOpe]

Thanks, Jacob, for your support and feedback! Glad you liked it. Let's see what Valerio thinks about the ASCII tree.

Appreciation your collaboration!

[Valerioageno]

I'm still skeptical about this solution:

1. The sum of all sizes is not a meaningful info (IMHO)
2. There is no mention of server side rendered routes and preloaded one
3. Vendor should be layout so it shouldn't be listed separately
4. No mention to the first load JS (I'd remove the Size column - keeping just the gzip version - and replace it with first load JS)

[HabeebullahOpe]

It's ok to doubtful, however you can just state the important parts and how you really want the implementation to work, and I will get that done without additional work.

[Valerioageno]

I shared the Next.js output because I think is the more clear solution:

Route                                             Size     First Load JS
┌ ○ /                                             6.52 kB        99.6 kB
├   └ css/fa842f4154849998.css   1.38 kB
├   /layout                                                          0 B                 93 kB
├   /protected
├   ├ ⦿  /                                                           6.52 kB        99.6 kB
├   └ ⦿  /dashboard                                          6.52 kB        99.6 kB
├ ○ /404                                                           190 B           93.2 kB
+ First Load JS shared by all                              
  └ chunks/main.js                       2.1 kB

○  (Static)   prerendered as static content
⦿  (Dynamic)  server-rendered on demand

IMHO, this has the most important infos. WDYT?

Sorry I can't format it correctly. I hope it is clear

[HabeebullahOpe]

Thanks for the clear direction! I'll follow your guidance and focus on the important parts as discussed. Ready to start the implementation.

Please let me know if there are any additional instructions or changes needed.

[HabeebullahOpe]

I think the clarification is better, it just makes the work easy, I just need to get the stuff ready instead of making doubts on what to use. Thanks once again, just waiting for your go ahead.

[Valerioageno]

My proposal has pretty much everything, IMO.

I'm not sure about other shared chunks (total) line. Probably we can get rid of it.

@jacobhq @marcalexiei WDYT?

[jacobhq]

I'm not sure about other shared chunks (total) line. Probably we can get rid of it.

I think so.

Also, what do we mean by gzip size - is that the size of the actual tsx file but gzipped, or the size of everything needed for that route gzipped? IMHO second one is what it should be.

Ready to start the implementation.

If everyone else is good with this, I think that may be best. Then we can give feedback on your actual code, which may be quicker. WDYT?

[marcalexiei]

I'm not sure about other shared chunks (total) line. Probably we can get rid of it.

I don't have a strong opinion about it.
When there is a table-like view I like I find natural to also have a "total row" at the bottom of it.
If you think that is not useful you can remove it.

[Valerioageno]

@jacobhq

Also, what do we mean by gzip size - is that the size of the actual tsx file but gzipped, or the size of everything needed for that route gzipped? IMHO second one is what it should be.

I meant the second one.

@marcalexiei

If you think that is not useful you can remove it.

Yeah, let's not have it for now. Let's see if in the future anyone will raise this need

@HabeebullahOpe I'd consider this our champion. Do you need anything else to start working on it?

[HabeebullahOpe]

Hey Valerio thanks for the clarification and I'm sorry I didn't follow up with last conversation had a simple task to complete. I understand that we mean the size of everything needed for the route gzipped. I'll proceed without including it for now, and we can revisit if there's need in the future.
Looks like I'm all set to proceed working.