webpack Team

A bundler for JavaScript and friends. Packs many modules into a few bundled assets.

Hosted by

Tobias Koppers's photoJuho Veps盲l盲inen's photoJohannes Ewald's photo

30th March 2016, 6:00 pm

This AMA is over!

Thank the host

What are the highlights of webpack 2?

  • new features?
  • breaking changes?
  • motivations?

We published a gist that explains the changes in detail. Here is a short summary:

webpack 2 will have native ES6 Modules support (including Code Splitting with ES6 through SystemJS semantics). The resolving backend changed as well. This means existing resolving plugins may no longer work and the configuration changed so that it hopefully makes more sense now. There are many small breaking changes that cover edge cases.

The motivation was to fix all the breaking changes that summarized during webpack 1 and to add ES6 support. Originally I also planned to change the ways loaders are configured, but I had no time to implement this. So this will probably be a plugin or webpack 3 thing.

Why did you create webpack in the first place?

What what the main motivation when you started the project?

Code Splitting.

I played with GWT (Google Web Toolkit) and loved Code Splitting. But there was nothing similar for pure JS. I proposed it to another bundler ( but quickly figured out that it鈥檚 difficult to add this to an existing bundler, because you need to design everything around it.

I did not create webpack, but I have an anecdote :)

In 2011, I've created a similar module as part of my bachelor thesis. I hadn't discovered browserify back then and I did not know about an AST, so I tried to "parse" the JavaScript with a RegExp (spoiler: don't even try to do this). Shortly after finishing the module, I realized that it was a stupid idea and maintenance hell. I switched to browserify and even contributed some lines to it. However, I quickly realized that browserify was not powerful enough (browserify@1 had a different architecture back then). I think, one main reason for me was code splitting as well. So I did a research and found webpack (having around 70 stars and some downloads). It had already all the features I was looking for:

  • Code splitting
  • Hashing
  • CommonJS + AMD support

So, I decided to give it a break (although there was almost no documentation available) and I think it was a good decision.

What is the best way to load essential modules first and fast, while lazy loading other modules in background?

Create an entry point for each place where a user can start using your page. This means in a SPA create multiple entry points if there are multiple pages. Put everything you need to display the page into that entry point. Everything else should be loaded on demand via Code Splitting. Use prefetching to trigger the download earlier, i.e., start the code download on hover.

If you want to get even faster, you can load expandable content on-demand or content below the fold too. Just trigger the code download when the initial stuff is displayed.

What is the best way to specify that a loader should compile a dependency from npm and have that working with npm link? I see that there are some issues with path.join and path.resolve with the resolve and resolveLoader settings.

I cannot give a good advice here. It's an issue that will be tackled with concord, but that's not done.

You can try to resolve the paths with enhanced-resolve like this:

var resolve = require("enhanced-resolve").create.sync({
  ...resolvingOptions, // same as webpack
  resolveToContext: true
}).bind(null, __dirname);

include: [

never tried this, but it's an idea.

Could you give us a small gist that demonstrates the problem? I think it depends on the use case because npm link is not a problem in general (in fact, I use it every day in my projects with webpack)

For sure.

I am using a repo that has React components as a dependency for another React project (let's call this the parent_repo), both of which use ES6 and 7 syntax. So I would like to use webpack with parent_repo and tell the babel loader to compile my child_repo, instead of the usual ignoring of node_modules. I'm trying to be able to develop fast locally by being able to npm link the child_repo and have webpack recompile both the parent and child, seeing changes with HMR. Perhaps even my setup is blasphemous.

When I use npm-link though, a lot of the resolving goes haywire. I have a number of plugins for the parent_repo and they cannot be found when the child_repo is compiling. Similar problems for loaders.

How do you compare Webpack with JSPM? Do you think they are different tools for different purposes?

I see JSPM as something more forward looking especially thanks to its HTTP/2 support. You can see some convergence, though, now that both JSPM and webpack 2 support SystemJS semantics. I feel that's one of the missing bits of the puzzle. ES6 gave us a module definition, but it failed to deliver a module loading mechanism. SystemJS gives just that.

I think the next year or two will show where JSPM will head as a project. It's always cool to see new tooling. There's still a lot of room for innovation in the space and competing projects are a good thing as long as you don't overdo it. Ideally we would find commonalities between projects to avoid reinventing the wheel too much.

Yes, diversity drives innovation! We should not think Open Source in a "corporate" way. It's all about ideas.

For instance: I really appreciate rollup's efforts on scope collpasing. Other projects are able to benefit from its insights.

Personally, I haven't discovered the real benefits of JSPM yet. I think it's misleading to say that JSPM is future proof, because imho ES2015 module loading semantics have not been figured out yet. Browser vendors and node.js contributors are still struggling with the actual implementation of the loader spec (that's at least what I can tell from my point of view).

Elimination of dead code has been the biggest pain for me when it comes to developing web apps. Are there any guidelines that should be followed to keep redundant code to a minimum? Also, is there any parallel to tree shaking for CSS?

  • Concentrate on one framework and as few libraries as possible.
  • Check if multiple versions of the some library are included in the bundle.
  • Use eslint to check if you import/requires are unused.
  • Update legacy code.
  • Write ES6 code.
  • Don鈥檛 use import * as xxx.

For CSS, write small CSS files that are used by components, avoid a big application.css.

Tree shaking for CSS will come鈥 Follow the CSS Modules development.

How does webpack 2 relates to rollupjs?

While they share some features, I think they both have different target audience.

webpack wants to help application developer, by supporting many different module types, weird configurations, silly dynamic dependencies, stylesheets, images, etc.. The output doesn鈥檛 need to look pretty as long as it works.

rollup wants to help the library developer, by supporting a pretty output format, tree shaking. It focus on ES6 trying a bring in new optimization possiblility, that were not possible with legacy module systems.

It depends on your needs.

How could we manage webpack projects depending on each other? (e.g. with different loader configurations) Will this improve in webpack 2?

There are plans for this (concord), but this is not fully implemented. There will be no improvement for the loader configuration, but there will be some improvement for the resolving configuration. see here:

What do you think about WebAssembly? Will it be challenging to the way we bundling our code?

Maybe, but it will take years to become mainstream. The next challenges will be HTTP2 and native ES6 Modules.

But WebAssembly will be something bundler developer need to consider in the future. Hopefully it will get transparent to the app developer then...

Tobias, when are you planning to get yourself a Twitter account?

Haha, I'd like to know that too :)

I barely have to time to implement webpack stuff.

But I follow the 鈥渨ebpack鈥 stuff on twitter to keep me up to date. (without an account)

What's your advice for beginner JavaScripters who want to contribute something to webpack development?

Don鈥檛 try to contribute the the webpack/webpack project directly. It鈥檚 propably too difficult for beginners. Try to start with loaders. There are many, they are usually pretty short and there is still much to do. You could also publish your own loaders if you think there is something missing.

Because of the babel configuration Webpack 2 forbids the usage of with. Unfortunately this doesn't work for underscore/lodash templates. Is there a solution to get around this issue?

Babel adds 鈥渦se strict鈥, which disallows with. webpack 2 should support modules with with as long as they don鈥檛 use strict mode. Don鈥檛 use babel for your templates.

How do you feel about HTTP/2.0? Considering things like: the bundling stuff isn't so "necessary", etc.

It's true some of the current best practices will change once HTTP/2.0 becomes prevalent. The problem is legacy support. I have a feeling we might need bundlers for quite a while.

Especially the streaming nature of HTTP/2.0 is neat. Loading a lot of small assets now would be a no go while it would be completely acceptable in HTTP/2.0 environment.

A lot depends on how soon clients adopt compatible browsers. Perhaps in some niche cases going full HTTP/2.0 would be acceptable already.

In my opinion it鈥檚 still necessary. Minimizing and Compression is more efficient when bundled. But HTTP2 offers more chances to optimize the output. I. e. we can create more output files to leverage better caching. webpack could emit a push configuration, which tells the server something about the dependency tree (good that we have a single dependency tree for JS, CSS and images).

Good question! And I already had some discussions about this.

I think, HTTP2 will not remove the need for tools like webpack. Webpack is not merging all JS files into one big chunk because of HTTP1. The main problem is the round-trip. For example: After you've send main.js to the client, the client figures out that it requires bootstrap.js as well and he requests it. Then you send bootstrap.js and after that, the client figures out that it also requires router.js and so on.

There's even a chance that HTTP2 will increase the need for a bundler. For example: If you want to levarage server push, you need to know your dependency graph. The dependency graph basically says: when the user requests index.html, he probably also needs main.js, bootstrap.js, router.js. This is only possible when you're using a tool which is able to process the AST and extract references on dependencies.

You could also do that based on statistics. But I still think it's pretty useful to have a tool which "understands" your source code and is able to perform some customizations on it (like C++ programers like to use preprocessor directives).

Do you work full time on webpack? Have you considered getting a company sponsor webpack development?

Only on my free time...

But I'm thinking about doing a crowdfunding to be able to dedicate 1-2 days per week to webpack. Maybe in exchange to some priority issue tracker.

I work around webpack through my SurviveJS effort. It generates income to allow me to push it further.

I'm currently working on a webpack specific guide and the plan is to funnel a part of the income directly to @sokra just to say thanks and help him find time to push the project further. I've also made a couple of moves earlier to make sure he is appreciated. :)

I wonder if something like Bountysource would work for webpack. There could be models like that which could help to support the development effort and perhaps broaden the developer base.

We are planing to support webpack by building a new website and improving docs. However, we did not manage to do anything so far because we're just a small company. We have to cover our costs first before investing into other projects.

If you're motivated and want to contribute to the docs, please don't hesitate :) I don't know when we will have time for this, so first come, first serve.

What's the plan with concord, and how does it tie in with Webpack 2.0? I noticed there's a few recent references to it in enhanced-resolve.

Sadly I had not enough time to implement the full concord support, but there will be stuff for the resolving part. You configurate the resolve directories, extensions and alias inside the package.json of a package. And this configuration can depend on the environment (i.e., different versions for browser and server). The same should come with the module type configuration from which the loader configuration is inferred.

The idea is to move more package-level configuration into the package.json (or bower.json) to make it easier to create frontend modules, which contain JS, CSS, images, etc.

This is a simplified scenario that I think other people can relate to, and has the following properties:

  • 2 React projects with a shared components repo, shared-repo.
  • shared-repo has its own dependencies on modules exclusive to the other 2 projects.
  • All React projects use ES6 and ES7 syntax. We use transform-decorators-legacy and jsx-control-statements as plugins.
  • We run with code with babel-node that programmatically start webpack.

It seems that the most effective way to have good development speed would be something like:

  1. Use npm link for shared-repo
  2. The main repos and shared-repo should be compiled with babel, the others modules should just be imported without compiling.
  3. When code is ready to be released we can use tags for the shared-repo and the main repo.

To me this scenario seems a simple one. If the assumption is that node_modules are compiled to ES5, ideally I would have like to just say in one line "use babel-loader for shared-repo but for no other dependencies".

When we were trying to implement this kind of workflow, it took a few days of trial and error. Most of the information we used to implement the solution was found in small parts of github issues. Our current webpack.config code for this setup takes up many lines, and even though it now works, we are unsure if it is overly-complicated or has undesired effects.

We think there are a number of sticking points. Firstly, resolve.modulesDirectories, resolve.fallback, resolve.root, resolveLoader.root, resolveLoader.fallback, module.loaders.include, module.loaders.exclude, externals interact with each others in as pipeline that we could not find documented to any large degree. The documentation provided seems to take these settings one-by-one, and often does not include examples of more complicated setups.

Secondly, we found the documentation very unclear for and From reading issues on github and other resources it seems like other users of webpack are also confused.

A few things we would love to have covered in more detail:

  • How paths are resolved and in which order
  • How to make simple import works without using relative syntax (import mod from 'shared-repo' vs import mod from '../../../../ shared-repo).
  • How inclusions and exclusions work for loaders (for our project that means what files are being compiled by babel-loader and what is not )
  • How does a .babelrc file in dependencies work when that dependency is being compiled by babel from another project (i.e. how can this file be ignored, for instance with with query?)
  • What needs to be an absolute paths and what need to be a relative path (aka path.join vs path.resolve) to makenpm link work with not only loaders, but also plugins.

First, I would like to understand what is the ideal solution for this scenario

Second, we think that the webpack community would benefit from a bit better documentation of the above list.

How paths are resolved and in which order

resolve.root => resolve.moduleDirectories => resolve.fallback

How to make simple import works without using relative syntax

resolve.root, resolve.alias in webpack.config.js

or since webpack 2 concord.modules in package.json

How inclusions and exclusions work for loaders

A module is processed by a loader when it's

  • matches any item in test and
  • matches any item in include and
  • doesn't match any item in exclude

How does a .babelrc file in dependencies work when that dependency is being compiled by babel from another project

That's not related to webpack but to babel.

Starting from the compiled file the next .babelrc file when going up the hierachy is used. (As far as I remember).

What needs to be an absolute paths and what need to be a relative path

absolute: context, output.path, strings in module.loaders.test/include/exclude, strings in module.noParse, *resolve.root, *resolve.fallback, resolve.modules, recordsPath, recordsInputPath, recordsOutputPath

relative or filename: resolve.moduleDirectories, output.filename, output.xxxFilename, resolve.modules, filename of extract-text-webpack-plugin, filename of SourceMapPlugin, filename of CommonsChunkPlugin

url: output.publicPath

module request: entry, values in resolve.alias

basically: path means absolute, filename means relative

The child compilation is really hard to understand - could you please give a brief overview how you would implement it correctly?

It's just another Compiler instance that result will be merged into the parent Compiler result. Most plugins are copied to the child compilation, but output options and entry point can be different.

The worker-loader gives are good overview of a correct implementation.

I agree that Webpack is powerful, but what do you think Webpack is not good at doing by its design choices?

External CSS file. The extract-text-plugin works fine but for me it always looks like a hack鈥 The problem is here that in webpack CSS is something dynamic and not compile-time constant. This makes it complex to put CSS into a static file. The current solution is the build the CSS into a JS file and evaluate this file to get the CSS source鈥 But I don鈥檛 know a better solution.

External CSS file

Agreed. Also, HTML files as entry points are still a big problem. A true module bundler for the web should also understand HTML as entry point :)

It would be cool to use webpack also for simple, static sites. This is already possible but it feels like a huge hack.

Is going to be improved? It seems pretty slow. We used that to compile .sass files. We do not use CSS modules. Building styles was taking up to 40 seconds. We ended up moving .sass compilation to gulp.

I've created a small alternative for the extract-text-webpack-plugin. You could give that a try. However, it does not cover all use-cases (e.g. collecting all stylesheets and merging them into one file).

It would be good to have some insight into this issue. I know that CSS compilation is slow in some projects. You could replace the css-loader with the raw-loader and check, if performance is significantly better and give us feedback.

It seems pretty slow.

I know. Please only use it when bundling for production. It'll compile each stylesheet twice by default ;)

What is the recommended knowledge for one to be able to help with developing webpack?

There is a fair amount of documentation tasks. Some have been marked as easy and would provide a good starting point. The rest require more research.

Helping to figure out people's problems and triaging issues would be helpful as well.

I don't think there's any particular recommended knowledge. It's more about willingness to figure things out. That said, webpack's source isn't the easiest and those who understand the design are few. :)

Is webpack-bootstrap outdated? It seems like it cannot find webpack-bootstrap in the global namespace

By the looks of it is the most current and maintained solution at the moment.

  • What are some cool webpack features you love, but aren't being used by others actively?

  • Any cool webpack tricks that most beginner/intermediates tend to overlook?

Hope you don't mind me asking multiple questions :D

What are some cool webpack features you love, but aren't being used by others actively?

This is a tough one. Perhaps hashing?

Any cool webpack tricks that most beginner/intermediates tend to overlook?

Plenty. I've tried to cover these in an upcoming guide.

I really like the AppCache manifest plugin, although it will be deprecated by the wide-spread adoption of ServiceWorkers. The AppCache manifest, however, still does a pretty decent job when you're developing a mobile app.

Regarding webpack tricks: I think, many developers don't know how to leverage file hashing correctly. If done right, the user only needs to download a small file after you've deployed a new release. If done wrong, the user needs to download all files again. For instance, you can store some information about the compilation in a webpack.records.json. With this information, webpack is able to re-use ids which prevents file hashes from being changed. @sokra has some interesting slides on this topic.

What are some cool webpack features you love, but aren't being used by others actively?

  • The target option. Compile to node.js and hot update your node.js application.
  • That HMR can be used in production too (Would really love to see someone doing this).
  • The chunk optimization plugins

Any cool webpack tricks that most beginner/intermediates tend to overlook?

90% of the features. Code Splitting, MultiCompiler, [chunkhash], Records are propably the most important ones.

Juho : What's the story behind SurviveJS? How did you come up with this plan?

I've written about this very topic at Agile Finland blog.

Long story short, there was no specific plan. If it wasn't for the community, I wouldn't be this far and would have given up a long time ago. So thanks guys. :)

What are the plans for the Webpack 2 documentation?

In order to improve the documentation situation I've been developing a little unofficial guide lately. Here's a sneak peek. It's task oriented. Feedback is very welcome as I would love to cover important topics there.

It's actually based on a little guide I wrote with Christian Alfoni about a year ago. Since then the guide morphed into a book about Webpack and React and now I'm splitting it up to make room for more detailed discussion. Back to the start I suppose.

The plan is to support webpack 2 within this book as it gets stable. Based on the What's new gist the changes are fairly minor. There could be some churn in the transition from webpack 1 to webpack 2 but we'll see.

I was thinking about re-designing the webpack website. I think, the current documentation is really hard for beginners. So it probably needs some restructuring. However, this is a big task 鈥 especially when everything needs to be done in the spare time.

I was planing to come up with a suggestion, especially a table of contents/site map and visual mocks. If you want to chime in: I've created an issue at webpack/docs

I use Figwheel a lot in my personal projects, it's like Webpack, but it appears that they have some difference. In Figwheel code is replaced directly and I don't have to handle the propagation. Amok is more like Figwheel and it just patches code at runtime. I mean it sounds they(Figwheel, Amok) are superior that we don't need to configure very much to make HMR work. Will Webpack update the HMR in the future?

It's quite possible this problem will be solved by tooling that wraps webpack and hides some of the complexity. You can see indications of this in form of tools like nwb or kotatsu. I don't see any definite winner yet, but no doubt some of these projects will become insanely popular once the stars align.

I don't know how how HMR with figwheel works, but Amok is a great addition to the live update ecosystem.

It work fundamental different than webpacks HMR. Amok uses the Chrome API to update code in place. It work at a very low level of the JS runtime.

webpacks HMR is a pure JS solution, which is browser independent.

Will Webpack update the HMR in the future?

Currently I see to need to change HMR. It's working fine and I like it as pure JS solution.

How does it feel to be the creator of a widely used open source project like webpack?

Really cool. I'm still shocked by the success. Thanks to Pete Hunt.

But at the same time I'm a bit sad because I can't dedicate more time to webpack. There is so much we can do we would have more time.

Dito. So many issues unread... However, I still try to review PRs with higher priority.

I had struggle using webpack with applications that are not SPA. The best example I can mention is It consists of many small SPAish applications. What strategy I have to follow to use webpack when developing these kind of applications? (multiple bundles?...)

multiple bundles?

yes. You can pass multiple entry points to webpack and it'll generate multiple bundles which can be used on different HTML pages.

But it would be better to design as SPA with routing and SSR, it would be much faster...

What is the use of devtool configuration option in webpack?

devtool generates sourcemaps. There are eval based alternatives in addition to something more conventional (separate file). Former is more suitable especially for development due to the performance benefit. As it bloats the bundle, you obviously want to avoid evaling for your production build.

The official documentation covers devtool in greater detail. It will take some experimentation to find the right options for your project.

I like eval the most. It's the fastest and I'm fine with seeing the babel output.

eval. Source maps can be tricky sometimes and there are probably still bugs in some loaders that don't map the source correctly...

This is the npm I was targeting Juho.

Based on the lack of activity around that specific package I would say it has been abandoned for now at least. The loader I linked to has active development effort going on.

What frontend framework do you admire and why?

I like React, Redux, CSS Modules, Babel.

I like the ideas of TypeScript and Relay, but don't use them because of the implementation architecture quality. Looks like they were not implemented by web people...

React because of immutable and declarative. Some for Redux. CSS Modules because of webpack and modularity. Babel because because I don't like the TypeScript implementation.

And I really like flexbox. So cool ;)

I have a soft spot for Cycle.js. It's conceptually simple and shows a lot of promise. Being made in Finland doesn't hurt.

I also like React and Redux. There are so many things that just feel right. Especially that Redux is more of a concept than an actual implementation.

I've also done a lot of work with rivets. It's a "classical" two-way data-binding library but really small and focused.

In terms of programming what else do you guys do apart from developing and maintaining webpack? How do you manage your time? What are your productivity hacks?

In terms of programming what else do you guys do apart from developing and maintaining webpack?

I do much C#. For web development ES6, JSX.

How do you manage your time?

no idea what to answer here. ;)

What are your productivity hacks?

I only answer issues that are fun to answer ;)

Even though I help to maintain the issue tracker (mainly tagging, answering when I can), my focus is actually around webpack. I've somehow managed to turn writing about technology into my profession. See SurviveJS to get a better idea. Here's a sneak peek at an upcoming webpack guide.

I've also done development in form of webpack-merge and webpack-presets. I had to develop former to make it easier to explain configuring webpack in my book. Incidentally the solution has found its way to my own projects. Latter project is a proof of concept about Babel style presets for webpack.

I feel there's room for innovation especially around webpack to make it easier and more fun to use.

I don't have any particular productivity hacks. I try to get something done every day, although I might take a few days off to enjoy Easter for example. As I enjoy this type of work (writing + technical bits), it really doesn't feel like work to me. If it starts to feel like work, I'm probably doing something wrong.

I've founded a small company with my friends. We're focused on JavaScript development and work for several clients. We try to develop as much as possible Open Source, but it's not always possible depending on the actual client.

Besides working for clients, we also teach at the local university and are organizing monthly meetups like Web&Wine or the Nodeschool Munich/Augsburg.

Unfortunately I don't have any productivity hacks. If you know one, let me know :). I would like to do much more Open Source, but there is little time. Recently, I've started to focus my efforts on projects where I'm the "main" maintainer.

I only answer issues that are fun to answer ;)

Haha, yeah... that's probably a good one

Can webpack be used as a build tool and replace gulp/grunt completely?

Yes, but that goes beyond the point. It is good to draw a line between task runners like Gulp or Grunt and bundlers like webpack or browserify. Bundlers do far less by definition. Even though you can find things like file copying plugins for webpack, it doesn't exactly excel there.

In practice a lot of people tend to use npm's package.json as a task runner for webpack. They define their tasks using the scripts section. Gulp and Grunt can be useful especially if you are worried about cross-platform support.

It's easy to write package.json scripts if you stick with Unix semantics for example. Writing something cross-platform is far harder due to differences (env variables, whatnot).

webpack is not a build tool. It's a bundler. If you only using gulp/grunt to build your javascript, css and images, webpack can replace it. But if you use the task runner for more stuff, like publishing, etc. webpack can't replace it.

webpack is not intented to be a generic task runner.

Gulp and Grunt can be useful especially if you are worried about cross-platform support.

With Windows 10 shipping with bash support in summer 2016, we hopefully won't have that issue anymore :)

What's your advice to someone that never contributed to webpack before start doing it right鈥 now? Maybe documentation etc?

The issue tracker has potential documentation tasks. See the tasks with easy documentation labels. Drop the easy label for more.

Generally it's easier to contribute around webpack than within it. This is something I have done with webpack-merge for example.

Contribution around loaders is also a good opportunity. The less used loaders are often not in the best quality or miss features.

Loaders are often pretty short and easy to understand. There is also a guide how to write loaders.

Thanks guys :)

Thanks for your time guys. :) What editors do you use to write JavaScript code?

Sublime (with vim bindings) and vim.

Sublime (without vim bindings ;) )

Webstorm and Atom for small example projects

(both without vim bindings :P)

As community members how can we help you guys keep contributing to webpack development? If you decide to start a kickstarter campaign, how soon will it be?

Would you recommend to use require hooks such as css-modules-require-hook & babel-register or would creating a server specific bundle would make more sense?

In my previous experience a server specific bundle was always the better decision in the long run. I think you should try to keep your client- and server-code as close as possible.

If you don't want to compile your entire server code with webpack, you can also think about splitting your app into a presentation layer and a data layer. The presentation layer will always be bundled with webpack, the data layer is just a separate node.js application which does not know anything about HTML and CSS. It just returns JSONs.

That's probably also a good separation of concerns :)

Are there any plans to be able run webpack CLI similar to the babel CLI, meaning that would run each files independently thru webpack and output it to a list folder?