Display bundle sizes after build

[thisbejim]

It would be great to see bundle sizes in the terminal after building a project, similar to the output of a create-react-app build.

[ntwcklng]

We could use a table formatter like https://github.com/Automattic/cli-table for this
I've created a draft which looks pretty nice:

1:

2:

Any other ideas?

[arunoda]

This looks great. But this list could grow since we might have more pages. Here's my suggestion.

• Use a simple list rather a table. (It saves space)
• Only show top 5 files (or some good amount)
• When showing pages, show pages/about.json like that.
• I prefer the first design for the uncompressed and gzipped sizes
• May be it's better to show the time spend for the build (and time for webpack and time for gzipping)

[transcranial]

why not use https://github.com/FormidableLabs/webpack-dashboard?

[ntwcklng]

@arunoda why do we have to save space? A list would take as much space as the table - if we want to display it readable (sizes on the same tab etc.)
I think this table is the perfect solution for outputting data like the bundle size.
To make it more compact, we can adjust the padding/margin from the cells.

For me, this is the perfect example how not to do it:

@transcranial this dashboard is maybe helpful when running next in dev mode. However, when you run next build you just need a lightweight list/table

[sedubois]

@ntwcklng I think he just means that the horizontal lines in the table aren't needed, they take up vertical space

[ntwcklng]

Okay, the alternative is console.table
Looks also pretty nice

Should we log the 5 overall largest files, or all bundle files + the 3 largest in pages/?

[arunoda]

@ntwcklng this looks pretty nice.
Shall we sort (z-a) by the size.
Ignore _document.json. It's a server only file.

[arunoda]

all bundle files + the 3 largest in pages/?

I like this.

[sakulstra]

I'd love to see this, but why restrict the output to ~5pages?
The project i'm working on has only ~10 and it would make sense for me to monitor the size for all of them.

Btw. would it be possible to not only display the size, but also the size difference to the previous build?

main.js    159kB (48.2kB) (+36.4kB)

[arunoda]

I not against of displaying ~10 pages. But I fear that'll be too much info. In this case, we mostly need to figure out our heavy pages. We need to limit upto few pages.

Btw. would it be possible to not only display the size, but also the size difference to the previous build?

I don't think this is possible. We do this only for production build (it doesn't make sense for the dev build) and it's not (most of the time) possible to compare with the previous bundle.

[ntwcklng]

I don't know if its a good idea to include the path in the output:

Should we just go with the basename for the pages?

If someone wants to test it: https://github.com/ntwcklng/next.js/tree/log-build-size

[sakulstra]

@arunoda but even comparing prouction build sizes(like create-react-app does as far as i know) would help a lot.

With this you can easily detect if you accidentally included the whole e.g. 'firebase' or 'lodash'... without a history the size is just a number, but if you can notice: "since last build my main.js is now 60kb bigger than before you can actually wonder where this comes from and figure out if the increasing file size is reasonable."

[nkzawa]

Btw, webpack2 supports options related to this topic.

https://webpack.js.org/configuration/performance/

We disable performance.hints for now.

Additionally, I wonder if this feature can be implemented by a webpack plugin. Ideally, I hope https://github.com/geowarin/friendly-errors-webpack-plugin supports this.

[timneutkens]

I'm +1 for adding it to friendly-errors-webpack-plugin. Created an issue for it to discuss.

[oliviertassinari]

For anyone looking into preventing bundle size regression. I have been solving a part of the issue with size-limit running in the CI:

.size-limit

[
  {
    "path": ".next/app.js",
    "webpack": false,
    "limit": "302.1 KB"
  },
  {
    "path": ".next/bundles/pages/www/home.js",
    "webpack": false,
    "limit": "35.4 KB"
  }
]

[julkue]

@timneutkens Since geowarin/friendly-errors-webpack-plugin#54 was closed and this ticke too, is there any follow-up ticket about this feature?

[dackers86]

Also keen to know if there has been any updates to this feature.

ParcelJS also has this and it's proved to be very useful.

[vonwao]

What does this ticket have to do with friendly errors? Anyways it looks like that got closed. I hate when tickets get linked to somewhere else and then closed. Seems like everyone liked this idea, why not merge it in?

[typeofweb]

Should this be reopened @timneutkens ?

[timmywil]

This ticket died for seemingly no reason. You can set config.performance to "error" to see the output for production builds in your next.config.js. However, the formatting is lost and it's just printed as an array of strings.

@timneutkens Would be great to either have an option to show webpack output during the build or have a hook for handling build errors so we can print these messages to the console (since webpack already made them pretty but they're stuck in an array).

Edit: Was just looking over the build code. Perhaps this could be addressed by printing the errors (and warnings?) from webpack stats individually in runCompiler. Then this could be closed by pointing to webpack performance hints. For instance, something like this...

if (jsonStats.errors.length > 0) {
  console.log()
  console.error.apply(console, jsonStats.errors)
  console.log.apply(console, jsonStats.warnings)
  // Don't include jsonStats in the error or it would just print it again when thrown
  return reject(new Error('Soft errors from webpack'))
}

[timneutkens]

Let's re-open it.

[lucleray]

I made a small plugin to do show bundle size when running next build. It's quite similar to some suggestions in this issue.

https://github.com/lucleray/next-size

@timneutkens Do you think it has its place in nextjs or it's better to keep it as a separate package ? create-react-app has something like that by default.

[timneutkens]

I think we should re-open this issue. I kind of don't want to add extra dependencies to Next.js at this point, so can we make it work with 0 dependencies?

[lucleray]

@timneutkens It should be possible 🙂

There's 3 dependencies :

• gzip-size => one line, using node's internal zlib library
• pretty-bytes => ~5 lines, or maybe there's something like this already in next.js ?
• chalk => we could "reuse" the dependency in webpackbar with a loose version pin, or just drop the colors

[timneutkens]

@lucleray sounds great to me, let's remove chalk for now and move those lines into the codebase with a comment referring back to the license

[lucleray]

Here's the PR : #5664

[timneutkens]

@lucleray solved this really well 😌