List of features we want to implement

[noomorph]

Drop in your ideas what else (new/improved) you want to see?

• [x] It should work realtime with webpack-dev-server and middleware
• [ ] It should feature a web-based version and an electron version
• [ ] It'd propably also give a deeper understanding of the webpack compilation and optimization options.
• [x] It should be compatible with Webpack 1.x and 2.x
• [ ] It should be extensible (via plugins or similarly) for enthusiasts who want other ways of visualization/analysis
• [ ] It should be able to display compilation steps in a flowchart-like way, so it's visual and easy to understand sequence of build steps and transitions between them

P.S. How we'll vote for the features by the way? Anything handy in Github for that? Not sure if +1 in comments is a clean way to do it :unamused:

[alajmo]

I think we should start of with asking questions and build the feature list off of that. Like,

• Who is this web app for? Beginners? People who already have extensive knowledge about webpack?
• What is the core functionality, exactly what are we trying to do? This would be great to get an example of, like: Input: X, Y, Output: Z.
• Besides providing some kind of analysis, what else is the purpose? Are we trying to popularize webpack, in this case, effort should be directed to making it easy to understand and get started.

Concerning votes, there's probably a 3rd-party web app we can create and share among ourselves.

[msuntharesan]

I Agree with @samiralajmovic. Another question should be

• At what point in the development this will be used?
  • Early stages of a project?
  • When it's ready for production and they are looking to eke out performance, reduce bundle size?

[sergey-lapin]

I think that we could make some minimal core app that will have comprehensible plugin api, so each plugin could do whatever it wants. We can put some plugins into the core as well, webpack structured in same way actually. We also can reuse some patterns from redux-devtools (lifting/unlifting actions, monitors api...). So let me put question differently, what data would be interesting to analize? I am also not sure that performance of production build is the most interesting thing, I am curious what we can do with omniscient of webpack about build during development as webpack really quick on rebuild - so we can have some analytics with instant feedback.

[msuntharesan]

Some ideas in regards to integrating with webpack directly

• With electron, It can hook directly into the webpack process when running to stream the stats and show live gui based build process.
• With webpack dev server and middleware, It can show the stats in a dedicated page
• I think the analysis should provide the users on what ways they can improve. Something like pagespeed. As an example of this, Let's say I've used the url-loader to include a large png image. And the the tool will suggest to set a limit for it.

[alajmo]

What do you guys think about mapping the work done by webpack to a flow-chart process as well? After all, Webpack goes through the imports / require (beginning with the entry file, as the root), and creates a map of it. It would provide a great overview of your project, seeing them in form of a graph / three illustration. In addition, a live walkthrough of the compilation could be seen: which files are piped through which loader etc. And all that is needed I assume is the stats object provided by the compiler.

Though, this is out of scope for now, and as @lapanoid mentioned, we should focus on building the core functionalities! Afterwards, we can use the provided data for prettier illustrations of the compilation, analyses etc once we have the basic platform. But it is always nice to get ahead of oneself!

[zaggy]

I think what @vanthiyathevan said is very interesting. Together with having a dedicated web app, it is worth considering to make it work with webpack-dev-server and middleware. That way, we can get the stats directly from webpack and just display the analysys on a dedicated webpage. Sound like something I would use in every dev project.

[louy2]

I would love to see the dependency graph @samiralajmovic mentioned!

[noomorph]

I wonder how hard will be analysis of unused exports (Webpack 2.0 feature), @sokra, have you added generating of such information to stats file?

[noomorph]

Guys, if anybody has experience with building Atom editor plugins - how do you think is possible to make webpack analyzer inside Atom or every another editor (as a plugin)?

I have no idea what is present right now on the market for Webpack integration with editors and IDEs, but maybe you do?

I'm heavy VIM user so I prefer stand-alone tools, but not everybody is like me - maybe it makes sense to add webpack analysis to IDEs like Webstorm or Atom (at least Atom is JavaScript, so maybe it's an easy cake to bite, what if we start from it?).

[sergey-lapin]

@noomorph that why I think we need some minimal abstract core and good plugin api, if we will have one people with different skill set could utilize it for IDE integration as well. I am not sure is there any way to keep same js codebase and use it with webstorm, maybe we even could try that: write js implementation of it - cover with tests - port to clojure - compile to Java - use it in webstorm plugin

[jnwng]

one of the problems i've encountered with the various optimization plugins is that while the descriptions of the plugins are useful, it would be much more powerful if you could "stage" or "preview" what those optimizations would do.

i imagine it would go along the lines of seeing how your chunk graph, selecting which optimizations you'd like to make, and seeing what the impact of those changes are immediately without having to re-compile (or potentially, just re-compiling with those options via a service worker or something) to basically "diff" what you had before and what you get with these optimizations. adding a couple sliders for the options for those plugins could help you better determine which values make the most sense for your application.

[jnwng]

also, based on my perusal of some of the issues, it would be very valuable to be able to easily share the stats.json file (of course, removing all the specific code related to those modules). i could imagine something like webpack.github.io/analyse-tool/some-id-here and being able to share that when attempting to debug different webpack configurations (but might be a little out of scope since i'm not certain these graphs are shared all that much)

[alajmo]

I feel the core features are pretty much set and can be worked on independently. If we can draft an ugly text mockup version, starting with the web version (I'm assuming it's going to be a bit more difficult doing realtime optimization with Atom?).