DISCOVERY: file filtering for more accurate analysis

[codecovdesign]

Problem to Solve

The current sorting mechanism in the bundle analysis page is non-intuitive, only sorting at the highest level. Users currently lack the ability to selectively filter or segment bundle contents when conducting bundle analysis.

Related following feedback also related to ongoing discovery around improved display/filtering.

However, something that would be really useful is some way to filter or split bundles when reporting. In its simplest form an option to specify which file extensions to include/exclude would suffice.
We are using Vite for our project and import our styles into the entry JS file, however when building for deployment we split out the CSS stuff into a separate file. This removes the styles themselves from the bundle analysis, but all the other stuff such as images and fonts that were included are still there.

In the above example the described limitation affects projects where assets such as CSS, images, and fonts are split from main JavaScript files during the build process but are still included in the overall bundle analysis. This inclusion can lead to misleading reporting, as the bundle size may appear larger than it is for the scripts alone, complicating efforts to monitor and optimize specific file types effectively.

Solution

• Consider a more detailed breakdown (such as: asset by size > type by size) and improved down/search/sort(?)
• Explore filtering capabilities that allow users to specify which file extensions to include or exclude from the reports. The goal is to enable more targeted and accurate bundle size tracking and reporting, allowing users to focus on specific asset types or to separate assets into different bundles based on their extensions.

WIP: designs

Investigation Tasks

Beta Give feedback

1. [engineering exploration] type filtering and grouping #1799
   investigation +1
   

API Tasks

Beta Give feedback

1. [API] Create GraphQL Schema #1895
   +0
   
2. [API] Delete deprecated code: moduleExtensions, sizeTotal, loadTimeTotal, deltas, assets.filters #1896
   +0
   
3. [Shared] Retrieve assets based on list of asset types and load types #1897
   +0
   
4. [Shared] Retrieve total size based on list of asset types and load types #1924
   +0
   
5. [API] Compute module count for a Bundle Report #1925
   +0
   
6. [API] Pass filters into shared.BundleReport.* #1898
   +0
   

UI Tasks

Beta Give feedback

1. Create multi-select for group types #1893
   +0
   
2. Create multi-select for load types #1894
   +0
   

[codecovdesign]

engineering/design discovery notes/questions

• user task: view bundle by grouping, per their designation in the PR report + UI repo level

  • IF user was looking to make this action, is there a world where they could make it in the UI OR would it be required to make it in the YAML? then in turn the grouping could be shown in the PR report (otherwise opt out)
  • OR if they made groupings in the UI would that be UI only? then they'd need to YAML config to show in repo
    • vu: codebase config, consider scenario when i'd like to organize by the page of our app UI

• review with VU

  • what would be helpful is to group by a page itself in UI/app
    - in the scenario that a file extends across groupings - helpful to identify that
    - how do we devise a system that takes into account - consider scenario where there is a duplication issue, since the sum total of the page (design consideration if multiple selection existed)
    - also would be helpful to group by:
    - 1) endpoint, 2) first loaded assets vs lazy loading assets
  • custom or generic
    • preferable to do custom grouping, since it's more flexible – then out of the box system could follow

[codecovdesign]

@katia-sentry @nicholas-codecov this issue is at the point where it's ready for investigation of:

1. filtering options, such as by type (css, js, html)
   • light ideation / other filtering by: first loaded assets vs lazy loading assets, duplicate dependencies
2. looking at concept of grouping, let's say by yaml, similar to components
   • configuration of grouping (UI or YAML); feels like yaml first approach, but curious if/how UI has any validity
   • IF yaml, can we convert those groups to be filters in the UI?

[nicholas-codecov]

first loaded assets vs lazy loading assets

We don't have any vis on this atm, that would require a lot more work in the plugins, plus some exploration to see if we can even do it

looking at concept of grouping, let's say by yaml, similar to components

What do you mean by this? I personally don't understand what users would want to be grouping on? things are already grouped via asset

[codecovdesign]

@nicholas-codecov

plus some exploration to see if we can even do it

Yes, that is the ask for the mini-investigation for that and the other items

looking at concept of grouping, let's say by yaml, similar to components
What do you mean by this?

we're exploring the ability to group bundle related items similar to how components or flags with our coverage product. examples of use case that came up is being able to view bundle details by page in-app (user would group related page assets) OR otherwise just parts of the bundle that are helpful to user/repo to monitor (filtering out less/not important items). Here is user quote of familiar sentiment ask "would be really useful is some way to filter or split bundles when reporting". so the problem focus is around surfacing the data within the bundle that is important to user.

In terms of the other items for investigation, such as filtering options, by type (css, js, html, images) – are there questions here or is this something we could explore/investigate further? any other filtering suggestions you think could help users?\

from sync 5/22:

• will explore more around 1) general type filtering, and 2) grouping (explore selecting modules/assets to view in filtered view)