Support for DllReferencePlugin?

[glenjamin]

Hello 👋

We're currently using relative-ci to track our bundle stats over time, but I've noticed that the modules that are externalised via the DllReferencePlugin are not included (which makes sense, they're not in the stats).

Is there any guidance on how to include these? If I add the agent plugin to the DLL build, will the results get merged correctly?

[vio]

@glenjamin, thank you for openening the issue!

Currently, we are tracking only one stats file per project. You can install the agent for the DLL compilation, but you'll need to send the stats to another RelativeCI project. You can create multiple projects for the same repo, like for a monorepo setup. Sending stats from multiple compilations to only one RelativeCI project will make the monitoring unusable since they will be compared with each other.

As a short-term workaround, the agent also has a CLI that consumes a webpack stats file, and in theory, it can be generated to include the stats from both compilations.

In the medium-long term, this case is something we want to support. If possible, can you please share more details about how you use the DLL plugin and how you think the data should be presented? (if you cannot share it here, feel free to send me an email at [email protected])

[glenjamin]

If possible, can you please share more details about how you use the DLL plugin

So interestingly my goal is to stop using the DLL plugin, since I don't think it's helping us much - we only use it on one project

I'm planning to replace the DLL bundle with a more usual splitChunk - so I want to get a proper side-by-side comparison

Do you have any experience in merging webpack stats JSONs from two different builds? It sounds like that should get me what I want

[vio]

So interestingly my goal is to stop using the DLL plugin, since I don't think it's helping us much - we only use it on one project

Thanks for sharing!:) We will wait for more feedback, though I am aware that Module Federation replaced some of its use cases (3x more usage for ModuleFederation on GitHub).

I'm planning to replace the DLL bundle with a more usual splitChunk - so I want to get a proper side-by-side comparison

I think you should be able to see the difference in the assets view, though the lack of corresponding module data might hide some insights.

Do you have any experience in merging webpack stats JSONs from two different builds? It sounds like that should get me what I want

The agent uses only a part of the webpack stats to generate the report. In theory, if webpack provides information about the bundled DLL modules and is enough to look up a corresponding module on the DLL compilation stats, they can be merged. It has been a while since i worked with a DllPlugin, i'm not sure if webpack provides any helpful information. I will try to create a test, though feel free to share webpack stats if possible.

[glenjamin]

I ended up replacing our use of the DLL plugin without needing a detailed bundle comparison, so I'm no longer personally motivated to improve the situation here.

I'll leave the issue open in case anyone else is looking in future, but feel free to close it if you'd prefer

[vio]

Thank you for sharing @glenjamin! Did you notice any difference in the assets view/total bundle size?

[glenjamin]

We effectively gained a new asset which was previously unaccounted for - what was formerly the DLL bundle, but is now just a chunk from the main buildAs a nice bonus, seeing it as part of the main build allowed us to spot a few more things that should be in it, so the change was a decent net saving in bundle sizeOn 7 Dec 2023, at 20:05, Viorel Cojocaru ***@***.***> wrote: Thank you for sharing @glenjamin! Did you notice any difference in the assets view/total bundle size? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[steverep]

@vio although not specifically using DLL or federation plugins, Home Assistant could benefit from being able to track an array of builds in one project. Right now, we have separate projects on RelativeCI for our modern and legacy builds, which means double the settings, status checks, etc.

While I would not want to lose the ability to view and interrogate the bundle stats separately, it would be nice to just track the aggregated totals for things like status checks or setting up a GitHub comment. I think a similar desire would apply to usage of DLL or federation plugins to break up a bundle.

[vio]

@steverep in the case of the DLL/Module federation builds, the data from another build counts towards the same metrics: Total bundle size, initial js, assets, modules, etc.

For monorepos, we are considering improving the management and the monitoring by groupping the projects, though the metrics will be calculated individually for each project. Isn't this something that will help more with your case with multiple bundles?

[steverep]

@steverep in the case of the DLL/Module federation builds, the data from another build counts towards the same metrics: Total bundle size, initial js, assets, modules, etc.

Oh I didn't realize that. Maybe I'm confused what this issue is exactly then. Can you point me to an example of what this looks like on RelativeCI?

For monorepos, we are considering improving the management and the monitoring by groupping the projects, though the metrics will be calculated individually for each project. Isn't this something that will help more with your case with multiple bundles?

Yes is my gut answer, but I think I need to understand DLL/Federation more to boost my confidence. TBH I've never used either.

In Home Assistant's case, we have 5 separate projects, each building 2 bundles (one for modern browsers and one for legacy). We only track the 2 we ship to users on RelativeCI. At a minimum, it would be nice to cut that in half by having a single check/approval/comment for each project by combining the modern and legacy, and also be able to see both the combined and separate stats. Maybe there's a way to do that with DLL or Federation but I haven't tried.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.