-
-
Notifications
You must be signed in to change notification settings - Fork 488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to filter to only initial JS by entrypoint #519
Add ability to filter to only initial JS by entrypoint #519
Conversation
eebdb15
to
5679ca9
Compare
80e6c05
to
d7b6a1e
Compare
d7b6a1e
to
618a359
Compare
Oh nice, this looks like a really useful feature! Thank you for the PR Do you think it's possible to also add test coverage going from a webpack stats JSON object to the end result? So that the test would look similar to e.g. what we have here: webpack-bundle-analyzer/test/analyzer.js Lines 187 to 192 in 83742b0
It would be nice if we could test the end result rather than only the |
@valscion Changed test format like you request |
Thanks! I'll take this PR for a test drive when I get a good slot some point in the future. I didn't spot any glaring issues when reading over the code quickly, so that's good. I'll review more closely when I have the time |
Thanks for taking a look @valscion. 🙂 I'm on @pas-trop-de-zele's team and we're glad to hear it'll be useful feature. |
Hey @valscion, just wanted to bump this to see if you'd get a chance to take a look, since this would be a really useful feature for us. I'd be happy to make any changes to the implementation if necessary. Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good enough to me! Are you able to add a changelog entry? And also fix the typo spotted in test code
I was also able to test this locally and this appears to be working as intended |
Co-authored-by: Vesa Laakso <[email protected]>
Thanks so much for taking a look @valscion! I added a changelog and fixed the typo – let me know if there's any other changes you'd like us to make before merging 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks!
CHANGELOG.md
Outdated
@@ -12,6 +12,9 @@ _Note: Gaps between patch versions are faulty, broken or test releases._ | |||
|
|||
## UNRELEASED | |||
|
|||
* **Improvement** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd classify this as a "New Feature", it's a nice addition!
This is now released in v4.7.0, thank you for your contributions! 🚀 |
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [webpack-bundle-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer) | devDependencies | minor | [`4.6.1` -> `4.7.0`](https://renovatebot.com/diffs/npm/webpack-bundle-analyzer/4.6.1/4.7.0) | --- ### Release Notes <details> <summary>webpack-contrib/webpack-bundle-analyzer</summary> ### [`v4.7.0`](https://github.com/webpack-contrib/webpack-bundle-analyzer/blob/HEAD/CHANGELOG.md#​470) [Compare Source](webpack-contrib/webpack-bundle-analyzer@v4.6.1...v4.7.0) - **New Feature** - Add the ability to filter to displaying only initial chunks per entrypoint ([#​519](webpack-contrib/webpack-bundle-analyzer#519) by [@​pas-trop-de-zele](https://github.com/pas-trop-de-zele)) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNC4xLjIiLCJ1cGRhdGVkSW5WZXIiOiIzNC4xLjIifQ==--> Co-authored-by: cabr2-bot <[email protected]> Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1608 Reviewed-by: Epsilon_02 <[email protected]> Co-authored-by: Calciumdibromid Bot <[email protected]> Co-committed-by: Calciumdibromid Bot <[email protected]>
Context
At the moment,
webpack-bundle-analyzer
allows filtering bundles by chunks which is very nice since that allows us to see what’s really inside our bundle and do appropriate optimization.However, there is not really a way for us to look at the initial JS being loaded. As a result, we added a filter to enable the ability to filter down to the initial chunks by entrypoint. This change would allow us to see the JS being loaded on the page before any dynamic imports are executed, which in lots of cases is responsible for app slow loading time
Changes
Added new
isInitialByEntrypoint
field to chunks object in chartData. This is a nested object with key being entrypoints and value being boolean if the chunk is initial for that entry pointThe reason for choosing nested object with boolean value instead of a more straightforward
Set
approach is thatSet
cannot be serialized andchartData
would have to be put on thewindows
object. The nested object option could be serialized while keeping the search performantScreenshot