Add rendered length to module

[doesdev]

Changes

This primarily makes two changes:

1. Adds renderedLength to Module

   • incremented whenever a module chunk is preRendered
   • exposed through ModuleJSON

2. More significantly, it is a breaking API change as OutputChunk.modules has been changed to ModuleJSON[] like the initial bundle

   • this allows exposing the renderedLength information where it matters (when it has a value)

Motivation

Now for the why. There is allot of value in knowing what each component is contributing to the bundle size, particularly after tree-shaken and rendered. There are numerous tools and plugins to provide insight into this info as best they can but the metrics on a per module basis aren't available as far as I could find.

Specifically I'm needing it for to address this issue in rollup-analyzer.

Considerations

I understand there's a good likelihood that this isn't a candidate for merging for a number of reasons. Likely there is a better way to do it for one. Secondly it's admittedly an intrusive change for what it provides, although I do think the insights will be very useful to the community.

If there is any variation on this theme that you could see getting merged I would be glad to implement with guidance.

[lukastaegert]

Thanks @doesdev. At the moment, @guybedford is reworking the plugin hooks in #2208 so this will have to wait until it is finished. Furthermore, the current direction is to reduce the API surface in this area.

Nevertheless I agree that it might be useful information for secondary tools that might also be included in some way in the reworked API (especially now that it is under active development). Maybe @guybedford has some thoughts on this.

As for the implementation, I was wondering why you increment the size for each call to pre-render. I assume that you think it is possible for a module to end up in more than one chunk like it is for webpack but this is actually not the case for rollup. Nevertheless as far as I can remember it is possible for prerender to be called more than once for a module in which case this approach would return incorrect results.

[guybedford]

Let me see if I can integrate something along these lines into #2208.

[guybedford]

@doesdev I've integrated an approach in #2208 for this, see #2208 (comment). Let me know if that information seems roughly like what you would need here.

[doesdev]

Awesome, thanks so much to both of you for the quick response and getting something in place so quick.

@guybedford Thanks for integrating that into the refactor, looks like just what I would need.

@lukastaegert Yeah, that is where my thinking was off on the implementation. Had made that faulty assumption.

I'm going to close this PR based on the solution in #2208