Replies: 12 comments
-
|
Wow that sounds like a super neat idea! I'm not sure if it fits within We could definitely extract useful bits out of this plugin to visualize loaders/plugins similarly to how I'd be excited to help with a proof of concept about this. |
Beta Was this translation helpful? Give feedback.
-
|
The most crucial part to even get to visualize this would be to get hands on to something similar as I don't know how much a webpack plugin can do to extract these timings, but it might be a nice adventure to go digging around webpack code to figure out places to attach such profiling code to 😄 |
Beta Was this translation helpful? Give feedback.
-
|
atm doing this is not really possible, I did a fair bit of research into making this exact tool. The next rev of tapable will expose the primitives that are needed, however plugins will need to upgrade tweet storm of findings |
Beta Was this translation helpful? Give feedback.
-
Not sure either, perhaps we could first build this in a fork of this repo and then look at whether to integrate it or make it a standalone repo. @samccone very cool, if the next tapable/webpack 4 will fix this it's perfect. This issue was not meant to be a quick fix so that's fine :). Do you plan to continue working on this when webpack 4 is released? |
Beta Was this translation helpful? Give feedback.
-
|
@SpaceK33z - IMO this feels like something that could be standalone and visualized via something like webpack-dashboard or the electron version //cc @kenwheeler and or printed out with the existing performance stats ( bundle size & so on ). @samccone - We can certainly ensure all the plugins that live here are updated accordingly and help drive the adoption for those plugins that live outside of contrib. If you are going to continue running with whatever this ends up being & want it to live inside of contrib, shoot me an DM & i'll get you into the org with the appropriate access to make the magics happen. |
Beta Was this translation helpful? Give feedback.
-
|
I believe you're right @d3viant0ne, that's also how the conversation lead to this idea. Would love to help with this. |
Beta Was this translation helpful? Give feedback.
-
|
More than happy to help. webpack 4 is going to be a hard requirement though, once that is out and we have enough plugins updated we can go from there. I think the next best step is to come up with a design doc around what this tool will show and what the user stories are around this tool and its findings. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Feel free to continue the conversation here, even though this issue isn't particularly about Seems like webpack 4 requirement is a must indeed. I hope someone of you will keep the ball rolling on this issue, as I don't have time to take a lead on this 💞 |
Beta Was this translation helpful? Give feedback.
-
|
@samccone did some work related to this https://twitter.com/TheLarkInn/status/945486181575340032 |
Beta Was this translation helpful? Give feedback.
-
|
This is the PR I would recommend following The plans are to land this in webpack#next as it required a pretty major plugin change to become possible |
Beta Was this translation helpful? Give feedback.
-
|
@samccone as I understand you've made your own visualization tool, right? |
Beta Was this translation helpful? Give feedback.
-
|
No, I made the export format loadable by which is what is captured in the screenshot above. |
Beta Was this translation helpful? Give feedback.
-
At ReactiveConf Tobias, Sean and I were asked multiple times "why is my build so slow". Also at other events I notice people don't know how to improve their webpack build time because they have no insights.
At the event we'd start explaining some basic performance optimizations, but also saying "it depends on what you're trying to do", or "make webpack do less work" (looking at you @TheLarkInn).
This lead me to think about bundle analyzer; this awesome tool allows us to visualize what's actually going in our bundle, size-wise. By giving these insights, you can actually tackle the problem that's resulting in huge builds.
What if we could do this, but for visualizing the build times? So instead of node packages you'd see "babel-loader", or "resolver plugin" or whatever takes up the most build time.
Some really spaceship ideas;
Feel free to close if this is really not something we want to do, but I wanted to just throw it out here and discuss. (not sure if this has been suggested before btw).
cc @sokra @CompuIves
Beta Was this translation helpful? Give feedback.
All reactions