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?

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 github.com as SPA with routing and SSR, it would be much faster...

Sublime (with vim bindings) and vim.

Sublime (without vim bindings ;) )

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.

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 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'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. :)

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: [
  resolve("some-module"),
  resolve("another-module")
]

never tried this, but it's an idea.

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.

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.

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.

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.

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).

By the looks of it https://www.npmjs.com/package/bootstrap-loader is the most current and maintained solution at the moment.

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.

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.

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

I barely have to time to implement webpack stuff.

But I follow the “webpack” stuff on twitter to keep me up to date. (without an account)

• 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’t 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.

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’t 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.

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.

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.

Don’t try to contribute the the webpack/webpack project directly. It’s 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.