4 ms·

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

by nnq 10y ago

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

jblok 10y ago
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.
tropin 10y ago
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".
- Sacho 10y ago
  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.
PhrosTT 10y ago
This is the best resource I've found so far: http://survivejs.com/webpack/introduction/ http://survivejs.com/webpack/introduction/
acemarke 10y ago
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 https://github.com/markerikson/react-redux-links [1] https://github.com/markerikson/react-redux-links/blob/master/webpack-tutorials.md https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/react-redux-links/blob/master/webpack-advanced-techniques.md https://github.com/markerikson/react-redux-links/blob/master...
badthingfactory 10y ago
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.
deco 10y ago
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.

by nnq 10y ago

jblok 10y ago

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.

tropin 10y ago

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

Sacho 10y ago
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.

PhrosTT 10y ago

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

acemarke 10y ago

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 https://github.com/markerikson/react-redux-links [1] https://github.com/markerikson/react-redux-links/blob/master/webpack-tutorials.md https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/react-redux-links/blob/master/webpack-advanced-techniques.md https://github.com/markerikson/react-redux-links/blob/master...

badthingfactory 10y ago

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.

deco 10y ago

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.