Tips and tricks in using Webpack | Hacker News Reader

Tips and tricks in using Webpack

github.com

97 pointsyedakesom19 comments

I'm more interested in an up-to-date "webpack for complete newbs with hairy hybrid-modern-legacy projects" resource, that would introduce you to everything from scratch with real examples.

Hopefully including more real-world cases than greenfield clean code projects: I want something like "start using webpack in an already started project that mixes jQuery & Backbone, React and some Polymer on a few pages, and a home-brewed-framework legacy portion" and maybe also has a few "isomorphic modules" (ya know, the kind of code that can run both in browser and in backend nodejs depending on context, but it "home made", not based on some nice magic sauce like Meteor). Because this is what you see in real world projects and the first questions when I tocuhed webpack were more along the lines of "how tf do I mix this old-school browsers global script + this commonjs/require one + this idiosincratic node-browser-isomorphic one" and "how to I tweak minification rules for one file only to prevent weird code breaks from variable renames"...

It's amazing how much modern js learning resources assume you already know! And how plain/normal they expect your project to be when in real life you're always seeing a mystic-quantum-chemistry-frankestein-puppy-hybrid thing :)

Your comment is spot on. I checked the webpack home hoping this tool somehow could optimize and/or clean inherited messed up projects with dozens of js libraries, only to learn that is up to the programmer to explicitly tell it the dependecies. At least, that's what I expected when I read "webpack simplifies your workflow by quickly constructing a dependency graph of your application and bundling them in the right order".

In order to construct the dependency graph, it still needs some mechanism through which to determine that a piece is dependent on another piece. Webpack uses several popular mechanisms for that(amd, commonjs, maybe others I dont know of), but they're all manual.

It sounds like you were looking for a tool more akin to UglifyJS or google's closure compiler, which(as far as I know) take a single file and analyze it, and then try to output "better" code equivalent to it.

Webpack tries to solve a different problem - from a bunch of scattered lego blocks you define an "application"(by defining dependencies), and have webpack bundle it together for you.

Webpack can help you with this. But I'm really sorry to tell you this... you're going to have to learn how to use it first.

If you have a specific use case and mangled array of libraries, frameworks and build systems, you can't expect it to be handled automatically by a magic new tool.

This is the best resource I've found so far: http://survivejs.com/webpack/introduction/

If it helps, my React/Redux links list ([0]) has two Webpack-related link categories: one for Webpack tutorials ([1]), and another for Webpack advanced techniques ([2]) such as build speed optimization, code splitting, Hot Module Reloading, etc. Plenty of good info linked from there.

[0] https://github.com/markerikson/react-redux-links

[1] https://github.com/markerikson/react-redux-links/blob/master...

[2] https://github.com/markerikson/react-redux-links/blob/master...

We recently moved a big piece of code from custom script loading -> requirejs -> webpack. I really couldn't even tell you how we managed to do it. I think it helped that we had a few goals in mind and we set out to find a better solution.

First, the custom js loading was buggy and inefficient so we moved it to requirejs. Then we wanted everything to be bundled into a single file so we figured out r.js. r.js was really slow and we wanted pre-compiled handlebars templates so we moved over to webpack. Now, we keep accidentally writing es2015 and breaking IE11 so it'll probably be time to introduce babel at some point.

It was really no different than any other major refactoring. Fix up the code and then chisel away the error messages one at a time.

We are at the tail end of introducing Webpack to an ~8yr old codebase and this has been our approach:

* Allocate training time for all team members to go through some e-learning courses / tutorials about Webpack (Frontend Masters, egghead.io, etc) and UMD (assorted tutorials / blog posts)

* After much hand-wringing we decided that for our situation converting our all-over-the-place JS codebase to UMDs with global fallbacks was the most flexible approach. This allows us to use the same code both in Webpack bundles and in our existing litany of <script> tags. Introducing Webpack has forced us to pay down a lot of technical debt during the process, something that has been years overdue but had to get done eventually. It's been frustrating having to clean up the mess made by developers who no longer work here but ¯\_(ツ)_/¯

* Created a long-running feature branch where we added Node.js and Webpack dependencies to our existing Java / Spring / Maven project

* As internal libraries are converted to UMD, merge them into the feature branch and add them to the appropriate Webpack bundle. Any 3rd party JS libraries that are available via npm have been removed from our codebase and are now pulled in as dependencies via package.json

* Put everything behind feature toggles

* Experiment with our CD / CI pipelines using the Webpack feature branch to make sure we can reliably break the Maven build when something goes wrong with Webpack / Node.js, generate fresh bundles for hot / partial deploys, and get things deployed to an app server in one of our dev environments without any issues

* Do demos every 2-3 weeks for both our team and other teams / managers to show progress, share lessons learned, etc

All of this has unfolded along with our regular workload over the last 3 months or so. We've taken a measured approach with small steps along the way and it's worked out well.

A lot of people are off for the holidays so my guess is we'll start introducing Webpack bundles into production sometime in mid-late January.

As an added benefit, this project has been used to establish a bit of a beachhead with respect to introducing Node.js to our various codebases so we can start doing automated testing, modern JS dependency management, code linting / style enforcement, and providing better developer tools to the team(s) that write JS / CSS / etc.

I think the webpack documentation is missing the "why" in a lot of cases, so I sometimes find it difficult to map my problems to the right area of docs.

The "vendor" and module splitting are good examples of this. Or, in this example, using "process.env.NODE_ENV" makes a lot of sense if you use Heroku, but is more cosmetic if you control the entire build chain.

NODE_ENV is just a convention though. Not specific to Heroku even if they might have popularized it.

I wrote a blog post recently that tries to clarify how and why `process.env.NODE_ENV` relates to JS build optimization: http://blog.isquaredsoftware.com/2016/11/posts-on-packtpub-g... .

That's really interesting, I didn't realize so many libraries depended on it, or that you could set it, thanks!

Awesome post!!! I'll reach out to our awesome-webpack companion repo and add this repo. Besides that, on behalf of the webpack core team, feel free and reach out if you have any other questions or want to get involved.

We even have a new docs page where hopefully _most_ of the things on this document are (if not should be) covered.

webpack.js.org webpack.js.org/concepts

~Sean + webpack Team

I have tried to make use of Webpack a few times for my projects but the only times I have actually managed is when starting on a new project with a boilerplate and config generator. The way it is set up doesn't seem to meld with my way of thinking at all.

I really like how straight forward Browserify is. Likely this is because I am quite accustomed to Unix shell tools and makefiles (I actually use Ninja [1] with ninja-build-gen [2] for a few of my Javascript projects) but Webpack's hot-reloading would be really nice to have.

I do think it would suffice if Browserify was a bit more performant so I don't have to wait for it after making a change. I keep meaning to try Rollup to see if it will give me any advantages in that regard.

[1]: http://ninja-build.org

[2]: https://www.npmjs.com/package/ninja-build-gen

Have you tried using watchify [1] to speed up your builds in development? I've also been using browserify-hmr [2] which is working nicely for hot module replacement and found it easier to setup than Webpack's hmr.

I think one of Webpack's benefits is that this stuff is all bundled with it, so everyone's using it but with browserify you need to go out and find these solutions yourself

[1]: https://www.npmjs.com/package/watchify

[2]: https://www.npmjs.com/package/browserify-hmr

Yes, I did try watchify but encountered some major errors during usage that made me give up. I might give it another go and see if it is solved now.

Ah, it never even occurred to me to look for something like browserify-hmr, will definitely try this out!

I've been running browserify under grunt and by itself, both using watchify, and I have no complaints. I came from just grunt, and a bunch of different tasks like concat, uglify, etc. Browserify has been a revelation, way faster compilation times, way less config, way fewer installed packages. Definitely give it a go again.

Booleans, how do they work?

  const DEBUG = process.env.NODE_ENV !== 'production'
  module.exports = {
    debug: DEBUG ? true : false

I wish I had had this a year ago. Literally every item listed I had to figure out awkwardly through digging around in github issues, blog posts, and stack overflow.

Reply on news.ycombinator.com