Usage with many bundles?

[phryneas]

Hi there, I'd love to test this with Apollo Client - but this plugin only seems to work with a single bundle config.

At AC, we use a bunch of these:

https://github.com/apollographql/apollo-client/blob/dc67e24e725c32ab62b7b3ce223fe211a16970ca/config/rollup.config.js#L159-L164

Is there any way to make this work?

[vio]

Hi @phryneas, thanks for creating the issue!

The plugin outputs the rollup stats in a webpack-stats format inside the bundle output folder. If you add the plugin to the prepareBundle, by default, you will get one webpack-stats.json file for each build:

⋊> ~/w/r/_/apollo-client on main ⨯ find dist -type f -name "*.json"
dist/core/webpack-stats.json
dist/cache/webpack-stats.json
dist/webpack-stats.json
dist/utilities/globals/webpack-stats.json
dist/utilities/webpack-stats.json
dist/utilities/subscriptions/urql/webpack-stats.json
dist/utilities/subscriptions/relay/webpack-stats.json
dist/testing/core/webpack-stats.json
dist/testing/webpack-stats.json
dist/link/remove-typename/webpack-stats.json
dist/link/context/webpack-stats.json
dist/link/core/webpack-stats.json
dist/link/retry/webpack-stats.json
....

If you need it for the other 2 builds, you can set the fileName option.

[!NOTE] make sure to add **/*/webpack-stats.json to .npmignore in case the dist folder is published to npm

---

Does this answer your question, or are you trying to achieve something else?

[plausible-phry]

I think that answers my question - I had assumed that I need to create a single webpack-stats.json in the end. Thank you!

Semi-related bonus question: Over in https://github.com/apollographql/apollo-client-nextjs we use tsup, which wraps around esbuild. Is it possible to create an output for relative-ci with that, too?

[phryneas]

Woops, wrong account - the above was me, if that wasn't clear :)

[vio]

@phryneas, it depends on how you would like to consume the stats, individually or together. Currently, we support only one stats file per build, but since the results are a bunch of JSON files, they can be combined into one single file. Can you share more details on how you plan to use the output?

Semi-related bonus question: Over in https://github.com/apollographql/apollo-client-nextjs we use tsup, which wraps around esbuild. Is it possible to create an output for relative-ci with that, too?

esbuild is not supported yet, but it is on our roadmap for Q2. I will let you know once we have a clear timeline ;)

[phryneas]

Can you share more details on how you plan to use the output?

I'm actually not sure yet what relative-ci can do, but I have to start somewhere, so I'm trying to set this up :)

Right now, we're doing a bunch of things very manually. Here's an example PR: https://github.com/apollographql/apollo-client/pull/11617

• We use size-limit to add reports on various different export sizes.
• We have a CI job to show us a diff of the build output in comparison with the upstream branch
• We use api-extractor to watch for accidental changes in our types
• We use AreTheTypesWrong to ensure that our type exports stay correct
• We have integration tests (e.g. with webpack and next.js) - maybe we could be warned if something fails tree-shaking? (I had quite the tree-shaking adventure today)

And a bunch more things (and tests of course).

It looks like relative-ci could at least do the first of those, maybe also the second - but I honestly don't really know yet.
Any input on what it can do to help us ship a good library would be very appreciated :)

[vio]

Sorry for being slow in connecting the dots, and thanks for taking the time to share your use case! :)

RelativeCI main use case has been to analyze and monitor medium/large applications, but since we started supporting roll-up/vite, more and more users have started analyzing and monitoring their libraries as well.

I recommend starting with the integration tests (webpack, next.js, etc). At this stage, you can analyze and track what is the real impact of the library on a real project:

• library impact on the app bundle size
• monitor how the library changes are impacting the app: new code, bundling regressions
• monitor dependencies: new transitive dependency, dependency bundle size regression, duplicate dependencies

The analysis is done for every build in comparison with the latest default branch, and it includes:

1. side by side comparison for assets, modules and packages (example)
2. insights: new dependency, duplicate dependencies (example)

In terms of reporting and notifications, a report summary can be added to pull requests, github checks, or sent to slack. Also, you can set up an automated review flow based on dynamic rules(https://relative-ci.com/documentation/setup/configure/integrations/github-commit-status-review) or forward the metrics to InfluxDB to correlate with other data.

• Documentation: Integrations
• PR example

Some open-source examples:

• outline/outline
• home-assistant/frontend
• concrete-utopia/utopia
• refined-github/refined-github
• scalar/scalar

---

RelativeCI can analyze and monitor the library files as well, but for this case, I think it is better if only one file is produced and ingested into a single project. This way, you can get all the changes across the builds and targets in one job analysis and view the summary in one PR comment/check report. We do not support injecting multiple stats for one single job, but i believe this can be done with a script before sending it to the service.

Let me know if you have any other questions ;)