10 ms·

Webpack 2.2 – Release Candidate

197 points by thelarkinn 10y ago

scrollaway 10y ago
Looking at the list of changes (https://webpack.js.org/guides/migrating/ https://webpack.js.org/guides/migrating/), it seems like a lot of "magic" has been removed. That's good. It's kinda funny how this is a very frequent pattern: Build something full of magic and, as you grow more mature and hit pain points, end up removing the magic. I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves. Anyone else with the same experience?
- baconomatic 10y ago
  Yep, I've become very fond of explicitness. Leaves nothing to question when others are working on the same code.
- fourstar 10y ago
  I'm a huge fan of verbosity.
- thelarkinn 10y ago
  Thank you guys for the positive feed back. If you find anything quirky or just want to get involved, feel free and drop us a github issue. ️
  - dictum 10y ago
    Hey Sean — I've been away from JS for a while and I'm just getting back, so I used Webpack for the first time this week. I always felt indifferent about it, and the config style felt a bit like Revenge of Grunt, but after using it and especially after reading your tweets and responses to issues on github, I finally understood why Webpack is so popular. I know project maintainers often work hard for little reward, but you're consistently gentle and helpful with beginners and people with complaints about Webpack. Thank you.
    - thelarkinn 10y ago
      Well thank you for always being candid and honest with your feedback to us. We really rely on feedback from the community who is ultimately in charge of the direction of this incredibly humbling project. This goes to more than just you, but please always feel welcome to reach out.
  - abritinthebay 10y ago
    As much as a give you crap on Twitter about Webpack I have to say: it's getting better day after day. Mostly due to less magic, tbh
    - dvlsg 10y ago
      Yeah, the sheer amount of magic was definitely my largest complaint about webpack. It's nice to see that the process is becoming a bit more explicit.
- zephraph 10y ago
  Oh man! That exactly describes my 2016 experience. We spent the entire year working on a project at work. It started off with a lot of magic to make on-boarding other "non-technical" people easier. After the summer we began ditching magic for a simplistic approach. The thing about magic is it's just as mystical when it breaks as it is when it works. That's why it's magic.
  - erikpukinskis 10y ago
    "The thing about magic is it's just as mystical when it breaks as it is when it works." That's the most concise way of describing the problem I've seen yet. I'm stealing that. Thank you!
- acemarke 10y ago
  Yep. That's one of the reasons why I love Redux, and why I don't quite get a lot of the complaints about it requiring "too much boilerplate". I've certainly looked for some ways to be a bit more DRY in using it, but there's also good reasons for having things like action type constants and action creator functions.
- tootie 10y ago
  Every time I look at my webpack config and it's nested properties with no descriptors I yearn for Maven and it's rigorously-defined XML.
  - sugarpile 10y ago
    Different strokes but I just had the severe displeasure of constructing a pom.xml for the first time and I would pay good money to never do it again. I would infinitely prefer to use JS tooling over Java's in general so maybe that's not saying much.
    - tootie 10y ago
      POM is not exactly intuitive, but the configuration directives are at least discoverable. If you're using a decent IDE, all the config options and values work with autocomplete. It's also pretty trivial to generate an archetype for most common needs. Webpack is practically a blank slate.
      - Sacho 10y ago
        But that's more of a documentation issue rather than an xml/json issue - you could certainly have an xml file without a schema. I think it mainly shows the maturity of Maven vs webpack(which is currently working hard on documenting everything).
- pkrefta 10y ago
  For me that's one of a reasons that as full-time Ruby/RoR developer I've started learning (& loving) Python. Some time ago I've started to realize that too much is happening under-the-hood in many of the libraries I'm using and somewhat in my applications. After few months Python is much more verbose and readable for me and I don't have dilemma whenever I should I implement certain thing this or that way.
  - owaislone 10y ago
    This thing kept me away from Ruby and RoR. I tried it a few times but never liked the magic after using Python/Django for a few years.
    - qwertyuiop924 10y ago
      Ruby is actually fairly good about this. RoR, OTOH...
      - hobarrera 10y ago
        The problem is that 90% of Ruby jobs are RoR jobs. It's a shame really, but true.
        qwertyuiop924 10y ago
        It is pretty sad. Especially considering that Ruby is like Smalltalk's weird younger cousin that is actually considered acceptable in The Industry.
- rl3 10y ago
  I find that where there'a magic, there's usually tutorial-style documentation. Not to say there's anything wrong with tutorial-style documentation in and of itself. However, it becomes problematic when it is the only documentation. Then you just find yourself digging around in source code because the "It's easy, simple and magic!" style of documentation turned out to be woefully inadequate, if not actively confusing.
  - patates 10y ago
    This situation keeps occurring especially with tooling. I guess one reason is that the tooling is there to bring in the magic in the first place. The other could be that tools being created because of the needs of a specific workflow and the magic is there because authors just wanted to have something working, then it got popular and now people want to use it in all sorts of workflows.
- julenx 10y ago
  > I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves. Speaking of magic or trying to be too clever with your code reminds me of the Grep Test [0], which I always try to conform. In the end it's not fun forcing others to deal with your magic. Remember: code is read way more often than it is written, so don't be lazy to type a bit more — help others. [0] http://jamie-wong.com/2013/07/12/grep-test/ http://jamie-wong.com/2013/07/12/grep-test/
- fusiongyro 10y ago
  Definitely. But I have come to appreciate a sprinkle of magic, especially if you can say show how the magic transforms something into something else that happens to be more verbose. Hibernate went through this too. I came to prefer myBatis, but going through JPA is nicer. JPA is certainly not less magical than Hibernate though, just the culmination of many years of work in this area. SQL Alchemy is also nice like this. The magical ORM is built on an extremely robust and well-documented relational database querying library. There's an escape hatch to reality if the magic fails you, always. Can't say that about Hibernate 3—see the HQL/Criteria API madness (again, fixed in JPA). I went through a very hyper-annotation period with Java. I have since calmed down. I still make annotations, occasionally, but I don't let them be the only route to the work. Always have the annotations help something build a configuration through a standard API, then the work happens against that configuration. You can ditch the annotations if they're a pain that way, or bridge between something else (XML probably) without writing the same code twice.
- sergiotapia 10y ago
  Smart defaults, allow configurations. That's the key. I learned how to use Webpack but still think it sucks and it's incredibly complicated for what it does for 90% of use cases. Smart defaults. -Then- let me configure if I need to.
  - mtrpcic 10y ago
    I solved this by keeping my Webpack build process in it's own repository, with a JSON file that dictates entry and exit points for builds. When doing a new frontend project, I use git submodules to import my build pipeline and just change a few variables and I'm set.
    - matallo 10y ago
      This sounds a lot like Grunt.
  - thelarkinn 10y ago
    Totally understand, now that webpack 2 is almost out the door, this is one of our top 5 overhauls we want to make. "Can we make smarter defaults" We support a lot of build targets and are agnostic to library and stack so it's going to be a challenge but with your help and the community I know we can get it done.
    - bpicolo 10y ago
      An alternative is a command line tool that could combine bits: webpack-make --scss --hot-middleware --blah or something, potentially?
      - thelarkinn 10y ago
        Do I have a github issue for you!!!! This is a feature tons of people ask for all the time so this week I officially marked it as RFC. https://github.com/webpack/webpack/issues/3466 https://github.com/webpack/webpack/issues/3466 Since the core team needs to focus on implementing more opt features like rollup and better top level minification, we left this for a chunk of our contribute team to help design and come up with. Help always wanted!!!
- eberkund 10y ago
  I used to wonder what people meant when describing "magic code" but after using a dynamic language MVC framework and seeing how things can be done different ways I have realized that mostly what people mean by that expression is using strings to indicate what code should be called rather than the features of the language. I'm somewhat undecided still on what to think of these sorts of patterns.
- qwertyuiop924 10y ago
  I avoid any library that is too magical. If a project asks you to just run this magical tool that will organize your source tree just so, and then it asks you to put your source code for each thing in a certain place, and don't worry about anything, it'll just work (cough cough RoR cough cough), then I'm not interested. Because sooner or later, it won't just work. And then I'll have to figure out what went wrong, which you won't have told us how to do.
- bryanrasmussen 10y ago
  The problem with magic - and I think it's the problem in webpack's case - is that magic is often predicated not on a clear model of how things work in your system but just a list of use cases that will be automatically handled without you having to think. However I think that if you have a clear model of how everything works you don't need that much magic because building the solution to any particular use case is not really an onerous task in itself.
ctulek 10y ago
It is hard to find well maintained JS libraries in these days. Thanks a lot for the mature work done here, especially in terms of documentation. So many OS projects launch their new shiny versions in such a rush, they leave their users in darkness for a very long time.
- dsissitka 10y ago
  Didn't they do that with 2.0? https://github.com/webpack/webpack/issues/3275 https://github.com/webpack/webpack/issues/3275
  - ctulek 10y ago
    This complaint looks to me about some devs jumping to use the alpha version of v2 and got confused about which version the homepage points to. This is separate and a minor problem which they have fixed anyways.
  - vmasto 10y ago
    No they didn't. Webpack 2 has been kept in alpha and beta for so long exactly because the documentation was lacking. If anything that fact alone shows a good amount of maturity.
  - madeofpalk 10y ago
    Their versioning strategy for 2.0 was pretty poor - it hasn't actually had a proper non-alpha/beta/rc yet until now. It was precisely documentation that was holding them back from declaring 2.x as 'stable'
mstijak 10y ago
webpack is great. HMR and code-splitting are killer features. Only thing that I'm worried about is tree shaking. There are a couple of long standing issues about problems with classes and export all statements. Rollup is missing code-spliting, webpack doesn't do tree shaking well and complains about bundle sizes. Not sure what to do. If somehow rollup could be integrated, that would be perfect.
- thelarkinn 10y ago
  We are really excited to work with Rich Harris on adding scope inlining, (Rollup'y) features. We were waiting to release 2 first :-D
- abritinthebay 10y ago
  HMR & code splitting weren't even original to WebPack... where does this fiction come from that it introduced them? (Side note - I have a complex app but still get ~1sec build times, why the fuss over HMR?)
  - kentor 10y ago
    Not having to refresh which means preserving state. If I have a modal opened and I want to make a change to the modal UI, if I refresh I would have to reopen the modal. With HMR the modal just rerenders. Also even if you have a fast build, refreshing might require refetching data from a server. In any case browserify also has HMR and it's great.
te_chris 10y ago
Quick, time for Laravel Elixir to find another beta version to bundle before an actual release happens...
fiatjaf 10y ago
This thing is so complicated and so full of magic and options and the documentation is so shallow, I can't find examples, can't get a tutorial that isn't uselessly superficial. I've tried using Webpack in its begginings, because React people only talked in Webpack terms, but then switched back to Browserify, which is simple, not magical and straightforward. I tried using Webpack again lately, with the bizarre Gatsby static site generator, and the failures are enourmous. I can't even understand how exactly does a loader work. Gatsby makes forced use of something called webpack-config or something like that, which is just a useless abstraction on top of the already confusing Webpack config. Please, someone explain to me what does this thing do that Browserify can't.
- lobster_johnson 10y ago
  Complicated, you say? https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large
  - fiatjaf 10y ago
    Did you just draw that?
    - thelarkinn 10y ago
      No that was handwritten by Tobias the original author and I shared it on Twitter a few weeks back. We do have a lot of abstraction and complexity internally. But we like the direction and way it has allowed us to pivot toward and away new/old features.
- vmasto 10y ago
  > Please, someone explain to me what does this thing do that Browserify can't. Nowadays not a lot more, but when it came out it was a revelation. The key thing to note is that replicating webpack's abilities in browserify takes about the same or more amount of config and boilerplate.
  - 10y ago
tonyhb 10y ago
Recently moved to this from webpack 1 for both personal projects and work. Webpack 2 combined with Yarn running inside of Docker to automate builds is the nicest (and fastest) frontend build pipeline I've had yet. The experience with Webpack2 is so much better: - Cleaner documentation - Saner configuration files: - It errors out if you add incorrect flags! - This means that postcss et. al. use config files - Saner module definitions (now called rules): - No query flags! - Actual object support! Plus tree shaking, code splitting etc. It's way better. Now looking forward to integrating babili within webpack to remove uglify. If you're thinking of upgrading it's not that much effort given the new documentation, too. Definitely worthwhile, and there seems to be less occasional build bugs using this with newer babel plugins (originally switched because of a crazy stackoverflow parsing a two-deep object).
- nicoburns 10y ago
  How have you found plug in support? The new features, etc look great, but I'm worried that there will lots of plugins that simply don't support the new version, or only have buggy bleeding edge versions that do....
  - tonyhb 10y ago
    There's `webpack.LoaderOptionsPlugin` which allows backwards compatibility, generally solves the problem. One word of warning: LoaderOptionsPlugin _may_ mess with "context", so you should always redefine it in each plugin option object. For example, using PostCSS without a .postcssrc: // postcss hasn't yet started to use options within rule definitons of // webpack 2; instead, we use a LoaderOptionsPlugin which provides // webpack 1 support of options to postcss. // https://github.com/postcss/postcss-loader/issues/92#issuecomment-251439696 new webpack.LoaderOptionsPlugin({ options: { // See https://github.com/postcss/postcss-loader/issues/99#issuecomment-248878925 and // https://github.com/webpack/webpack/issues/3018#issuecomment-248445176 context: __dirname, postcss: [ require('postcss-mixins'), require('postcss-simple-vars'), // TODO: Remove and use css variables (http://cssnext.io/features/#custom-properties-var) require('postcss-constants')({ defaults: defaults }), require('postcss-each'), require('postcss-cssnext')({ browsers: 'last 2 versions', features: { // https://github.com/robwierzbowski/node-pixrem/issues/40 rem: false }, import: true, compress: false, messages: true }), require('postcss-nested'), require('lost') ] } }) You can get around this by using a postcss plugin to read from the common config file (.postcssrc iirc) also, but I depend on requires for postcss-constants so couldn't.
sotojuan 10y ago
We have an ejected CRA web pack confit that I wanna update to 2 eventually. What's a good migration guide?
- thelarkinn 10y ago
  Check the actual article and you'll see the v1-v2 migration link embedded into the post!!!
- deleted 10y ago
  [deleted]
msoad 10y ago
One big question I have from Webpack is this: In age of HTTP/2 packing is not recommended anymore but I love so many features of Webpack, are you guys going to adopt to HTTP/2 paradigms? Great work, thanks!
- thelarkinn 10y ago
  We have a plugin built around the research on HTTP/2 and web perf (which based on the data so far points to bundling still yielding the optimal results) called AgressiveSplittingPlugin. It's designed to allow you to specify a max and min file size and webpack(2) will create x bundles of those size up to a certain number (if specifies). The advantages are now you are drastically increasing the delivery of your js and other assets but still bundled for opt. Sokra (Tobias) wrote an article about this research if you are interested!! https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.5ycapkafg https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.5yca... Also to see an example of the API usage you can visit our core repo under examples where we explain the trade offs (compression vs cacheability): https://github.com/webpack/webpack/tree/master/examples/http2-aggressive-splitting https://github.com/webpack/webpack/tree/master/examples/http...
- deleted 10y ago
  [deleted]
ahayter 10y ago
Thank goodness I decided to bite the bullet last week and make the jump to v2. Upgrade took a while but was rather painless thanks to the great migration guide on the new documentation site. If you are using a ton of loaders that aren't v2 ready you may have a more painful experience, you'll have to get familiar with the LoaderOptionsPlugin. If you're newish to webpack it could be a frustrating experience. Shout out to the webpack team though, It's an impressive tool.
- progx 10y ago
  I wait some month until the major Loaders are Webpack 2 ready. Don't have time to waste in such things.
julenx 10y ago
Reading through the Webpack2 release tags I came across the v2.1.0-beta28 changelog, which mentions: > * add `import()` as Code Splitting construct. It should be used instead of `System.import` when possible. `System.import` will be deprecated in webpack 2 release (removed in webpack 3) as it's behavior is incorrect according to the spec. I was under the impression `System.import` would be the new way to do code splitting and hence supersede `require.ensure()`. After further checking, now it seems like the function-like `import()` will be used instead [1], which is better accepted in browsers than `System.import()`. [0] https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.28 https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.... [1] https://github.com/webpack/webpack/issues/3098 https://github.com/webpack/webpack/issues/3098

197 points by thelarkinn 10y ago

Looking at the list of changes (https://webpack.js.org/guides/migrating/ https://webpack.js.org/guides/migrating/), it seems like a lot of "magic" has been removed. That's good. It's kinda funny how this is a very frequent pattern: Build something full of magic and, as you grow more mature and hit pain points, end up removing the magic. I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves. Anyone else with the same experience?

baconomatic 10y ago
Yep, I've become very fond of explicitness. Leaves nothing to question when others are working on the same code.
fourstar 10y ago
I'm a huge fan of verbosity.
thelarkinn 10y ago
Thank you guys for the positive feed back. If you find anything quirky or just want to get involved, feel free and drop us a github issue. ️
- dictum 10y ago
  Hey Sean — I've been away from JS for a while and I'm just getting back, so I used Webpack for the first time this week. I always felt indifferent about it, and the config style felt a bit like Revenge of Grunt, but after using it and especially after reading your tweets and responses to issues on github, I finally understood why Webpack is so popular. I know project maintainers often work hard for little reward, but you're consistently gentle and helpful with beginners and people with complaints about Webpack. Thank you.
  - thelarkinn 10y ago
    Well thank you for always being candid and honest with your feedback to us. We really rely on feedback from the community who is ultimately in charge of the direction of this incredibly humbling project. This goes to more than just you, but please always feel welcome to reach out.
- abritinthebay 10y ago
  As much as a give you crap on Twitter about Webpack I have to say: it's getting better day after day. Mostly due to less magic, tbh
  - dvlsg 10y ago
    Yeah, the sheer amount of magic was definitely my largest complaint about webpack. It's nice to see that the process is becoming a bit more explicit.
zephraph 10y ago
Oh man! That exactly describes my 2016 experience. We spent the entire year working on a project at work. It started off with a lot of magic to make on-boarding other "non-technical" people easier. After the summer we began ditching magic for a simplistic approach. The thing about magic is it's just as mystical when it breaks as it is when it works. That's why it's magic.
- erikpukinskis 10y ago
  "The thing about magic is it's just as mystical when it breaks as it is when it works." That's the most concise way of describing the problem I've seen yet. I'm stealing that. Thank you!
acemarke 10y ago
Yep. That's one of the reasons why I love Redux, and why I don't quite get a lot of the complaints about it requiring "too much boilerplate". I've certainly looked for some ways to be a bit more DRY in using it, but there's also good reasons for having things like action type constants and action creator functions.
tootie 10y ago
Every time I look at my webpack config and it's nested properties with no descriptors I yearn for Maven and it's rigorously-defined XML.
- sugarpile 10y ago
  Different strokes but I just had the severe displeasure of constructing a pom.xml for the first time and I would pay good money to never do it again. I would infinitely prefer to use JS tooling over Java's in general so maybe that's not saying much.
  - tootie 10y ago
    POM is not exactly intuitive, but the configuration directives are at least discoverable. If you're using a decent IDE, all the config options and values work with autocomplete. It's also pretty trivial to generate an archetype for most common needs. Webpack is practically a blank slate.
    - Sacho 10y ago
      But that's more of a documentation issue rather than an xml/json issue - you could certainly have an xml file without a schema. I think it mainly shows the maturity of Maven vs webpack(which is currently working hard on documenting everything).
pkrefta 10y ago
For me that's one of a reasons that as full-time Ruby/RoR developer I've started learning (& loving) Python. Some time ago I've started to realize that too much is happening under-the-hood in many of the libraries I'm using and somewhat in my applications. After few months Python is much more verbose and readable for me and I don't have dilemma whenever I should I implement certain thing this or that way.
- owaislone 10y ago
  This thing kept me away from Ruby and RoR. I tried it a few times but never liked the magic after using Python/Django for a few years.
  - qwertyuiop924 10y ago
    Ruby is actually fairly good about this. RoR, OTOH...
    - hobarrera 10y ago
      The problem is that 90% of Ruby jobs are RoR jobs. It's a shame really, but true.
      - qwertyuiop924 10y ago
        It is pretty sad. Especially considering that Ruby is like Smalltalk's weird younger cousin that is actually considered acceptable in The Industry.
rl3 10y ago
I find that where there'a magic, there's usually tutorial-style documentation. Not to say there's anything wrong with tutorial-style documentation in and of itself. However, it becomes problematic when it is the only documentation. Then you just find yourself digging around in source code because the "It's easy, simple and magic!" style of documentation turned out to be woefully inadequate, if not actively confusing.
- patates 10y ago
  This situation keeps occurring especially with tooling. I guess one reason is that the tooling is there to bring in the magic in the first place. The other could be that tools being created because of the needs of a specific workflow and the magic is there because authors just wanted to have something working, then it got popular and now people want to use it in all sorts of workflows.
julenx 10y ago
> I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves. Speaking of magic or trying to be too clever with your code reminds me of the Grep Test [0], which I always try to conform. In the end it's not fun forcing others to deal with your magic. Remember: code is read way more often than it is written, so don't be lazy to type a bit more — help others. [0] http://jamie-wong.com/2013/07/12/grep-test/ http://jamie-wong.com/2013/07/12/grep-test/
fusiongyro 10y ago
Definitely. But I have come to appreciate a sprinkle of magic, especially if you can say show how the magic transforms something into something else that happens to be more verbose. Hibernate went through this too. I came to prefer myBatis, but going through JPA is nicer. JPA is certainly not less magical than Hibernate though, just the culmination of many years of work in this area. SQL Alchemy is also nice like this. The magical ORM is built on an extremely robust and well-documented relational database querying library. There's an escape hatch to reality if the magic fails you, always. Can't say that about Hibernate 3—see the HQL/Criteria API madness (again, fixed in JPA). I went through a very hyper-annotation period with Java. I have since calmed down. I still make annotations, occasionally, but I don't let them be the only route to the work. Always have the annotations help something build a configuration through a standard API, then the work happens against that configuration. You can ditch the annotations if they're a pain that way, or bridge between something else (XML probably) without writing the same code twice.
sergiotapia 10y ago
Smart defaults, allow configurations. That's the key. I learned how to use Webpack but still think it sucks and it's incredibly complicated for what it does for 90% of use cases. Smart defaults. -Then- let me configure if I need to.
- mtrpcic 10y ago
  I solved this by keeping my Webpack build process in it's own repository, with a JSON file that dictates entry and exit points for builds. When doing a new frontend project, I use git submodules to import my build pipeline and just change a few variables and I'm set.
  - matallo 10y ago
    This sounds a lot like Grunt.
- thelarkinn 10y ago
  Totally understand, now that webpack 2 is almost out the door, this is one of our top 5 overhauls we want to make. "Can we make smarter defaults" We support a lot of build targets and are agnostic to library and stack so it's going to be a challenge but with your help and the community I know we can get it done.
  - bpicolo 10y ago
    An alternative is a command line tool that could combine bits: webpack-make --scss --hot-middleware --blah or something, potentially?
    - thelarkinn 10y ago
      Do I have a github issue for you!!!! This is a feature tons of people ask for all the time so this week I officially marked it as RFC. https://github.com/webpack/webpack/issues/3466 https://github.com/webpack/webpack/issues/3466 Since the core team needs to focus on implementing more opt features like rollup and better top level minification, we left this for a chunk of our contribute team to help design and come up with. Help always wanted!!!
eberkund 10y ago
I used to wonder what people meant when describing "magic code" but after using a dynamic language MVC framework and seeing how things can be done different ways I have realized that mostly what people mean by that expression is using strings to indicate what code should be called rather than the features of the language. I'm somewhat undecided still on what to think of these sorts of patterns.
qwertyuiop924 10y ago
I avoid any library that is too magical. If a project asks you to just run this magical tool that will organize your source tree just so, and then it asks you to put your source code for each thing in a certain place, and don't worry about anything, it'll just work (cough cough RoR cough cough), then I'm not interested. Because sooner or later, it won't just work. And then I'll have to figure out what went wrong, which you won't have told us how to do.
bryanrasmussen 10y ago
The problem with magic - and I think it's the problem in webpack's case - is that magic is often predicated not on a clear model of how things work in your system but just a list of use cases that will be automatically handled without you having to think. However I think that if you have a clear model of how everything works you don't need that much magic because building the solution to any particular use case is not really an onerous task in itself.

ctulek 10y ago

It is hard to find well maintained JS libraries in these days. Thanks a lot for the mature work done here, especially in terms of documentation. So many OS projects launch their new shiny versions in such a rush, they leave their users in darkness for a very long time.

dsissitka 10y ago
Didn't they do that with 2.0? https://github.com/webpack/webpack/issues/3275 https://github.com/webpack/webpack/issues/3275
- ctulek 10y ago
  This complaint looks to me about some devs jumping to use the alpha version of v2 and got confused about which version the homepage points to. This is separate and a minor problem which they have fixed anyways.
- vmasto 10y ago
  No they didn't. Webpack 2 has been kept in alpha and beta for so long exactly because the documentation was lacking. If anything that fact alone shows a good amount of maturity.
- madeofpalk 10y ago
  Their versioning strategy for 2.0 was pretty poor - it hasn't actually had a proper non-alpha/beta/rc yet until now. It was precisely documentation that was holding them back from declaring 2.x as 'stable'

mstijak 10y ago

webpack is great. HMR and code-splitting are killer features. Only thing that I'm worried about is tree shaking. There are a couple of long standing issues about problems with classes and export all statements. Rollup is missing code-spliting, webpack doesn't do tree shaking well and complains about bundle sizes. Not sure what to do. If somehow rollup could be integrated, that would be perfect.

thelarkinn 10y ago
We are really excited to work with Rich Harris on adding scope inlining, (Rollup'y) features. We were waiting to release 2 first :-D
abritinthebay 10y ago
HMR & code splitting weren't even original to WebPack... where does this fiction come from that it introduced them? (Side note - I have a complex app but still get ~1sec build times, why the fuss over HMR?)
- kentor 10y ago
  Not having to refresh which means preserving state. If I have a modal opened and I want to make a change to the modal UI, if I refresh I would have to reopen the modal. With HMR the modal just rerenders. Also even if you have a fast build, refreshing might require refetching data from a server. In any case browserify also has HMR and it's great.

te_chris 10y ago

Quick, time for Laravel Elixir to find another beta version to bundle before an actual release happens...

fiatjaf 10y ago

This thing is so complicated and so full of magic and options and the documentation is so shallow, I can't find examples, can't get a tutorial that isn't uselessly superficial. I've tried using Webpack in its begginings, because React people only talked in Webpack terms, but then switched back to Browserify, which is simple, not magical and straightforward. I tried using Webpack again lately, with the bizarre Gatsby static site generator, and the failures are enourmous. I can't even understand how exactly does a loader work. Gatsby makes forced use of something called webpack-config or something like that, which is just a useless abstraction on top of the already confusing Webpack config. Please, someone explain to me what does this thing do that Browserify can't.

lobster_johnson 10y ago
Complicated, you say? https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large https://pbs.twimg.com/media/CxfCRzbVQAAXszJ.jpg:large
- fiatjaf 10y ago
  Did you just draw that?
  - thelarkinn 10y ago
    No that was handwritten by Tobias the original author and I shared it on Twitter a few weeks back. We do have a lot of abstraction and complexity internally. But we like the direction and way it has allowed us to pivot toward and away new/old features.
vmasto 10y ago
> Please, someone explain to me what does this thing do that Browserify can't. Nowadays not a lot more, but when it came out it was a revelation. The key thing to note is that replicating webpack's abilities in browserify takes about the same or more amount of config and boilerplate.
- 10y ago

tonyhb 10y ago

Recently moved to this from webpack 1 for both personal projects and work. Webpack 2 combined with Yarn running inside of Docker to automate builds is the nicest (and fastest) frontend build pipeline I've had yet. The experience with Webpack2 is so much better: - Cleaner documentation - Saner configuration files: - It errors out if you add incorrect flags! - This means that postcss et. al. use config files - Saner module definitions (now called rules): - No query flags! - Actual object support! Plus tree shaking, code splitting etc. It's way better. Now looking forward to integrating babili within webpack to remove uglify. If you're thinking of upgrading it's not that much effort given the new documentation, too. Definitely worthwhile, and there seems to be less occasional build bugs using this with newer babel plugins (originally switched because of a crazy stackoverflow parsing a two-deep object).

nicoburns 10y ago
How have you found plug in support? The new features, etc look great, but I'm worried that there will lots of plugins that simply don't support the new version, or only have buggy bleeding edge versions that do....
- tonyhb 10y ago
  There's `webpack.LoaderOptionsPlugin` which allows backwards compatibility, generally solves the problem. One word of warning: LoaderOptionsPlugin _may_ mess with "context", so you should always redefine it in each plugin option object. For example, using PostCSS without a .postcssrc: // postcss hasn't yet started to use options within rule definitons of // webpack 2; instead, we use a LoaderOptionsPlugin which provides // webpack 1 support of options to postcss. // https://github.com/postcss/postcss-loader/issues/92#issuecomment-251439696 new webpack.LoaderOptionsPlugin({ options: { // See https://github.com/postcss/postcss-loader/issues/99#issuecomment-248878925 and // https://github.com/webpack/webpack/issues/3018#issuecomment-248445176 context: __dirname, postcss: [ require('postcss-mixins'), require('postcss-simple-vars'), // TODO: Remove and use css variables (http://cssnext.io/features/#custom-properties-var) require('postcss-constants')({ defaults: defaults }), require('postcss-each'), require('postcss-cssnext')({ browsers: 'last 2 versions', features: { // https://github.com/robwierzbowski/node-pixrem/issues/40 rem: false }, import: true, compress: false, messages: true }), require('postcss-nested'), require('lost') ] } }) You can get around this by using a postcss plugin to read from the common config file (.postcssrc iirc) also, but I depend on requires for postcss-constants so couldn't.

sotojuan 10y ago

We have an ejected CRA web pack confit that I wanna update to 2 eventually. What's a good migration guide?

thelarkinn 10y ago
Check the actual article and you'll see the v1-v2 migration link embedded into the post!!!
deleted 10y ago
[deleted]

msoad 10y ago

One big question I have from Webpack is this: In age of HTTP/2 packing is not recommended anymore but I love so many features of Webpack, are you guys going to adopt to HTTP/2 paradigms? Great work, thanks!

thelarkinn 10y ago
We have a plugin built around the research on HTTP/2 and web perf (which based on the data so far points to bundling still yielding the optimal results) called AgressiveSplittingPlugin. It's designed to allow you to specify a max and min file size and webpack(2) will create x bundles of those size up to a certain number (if specifies). The advantages are now you are drastically increasing the delivery of your js and other assets but still bundled for opt. Sokra (Tobias) wrote an article about this research if you are interested!! https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.5ycapkafg https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.5yca... Also to see an example of the API usage you can visit our core repo under examples where we explain the trade offs (compression vs cacheability): https://github.com/webpack/webpack/tree/master/examples/http2-aggressive-splitting https://github.com/webpack/webpack/tree/master/examples/http...
deleted 10y ago
[deleted]

ahayter 10y ago

Thank goodness I decided to bite the bullet last week and make the jump to v2. Upgrade took a while but was rather painless thanks to the great migration guide on the new documentation site. If you are using a ton of loaders that aren't v2 ready you may have a more painful experience, you'll have to get familiar with the LoaderOptionsPlugin. If you're newish to webpack it could be a frustrating experience. Shout out to the webpack team though, It's an impressive tool.

progx 10y ago
I wait some month until the major Loaders are Webpack 2 ready. Don't have time to waste in such things.

julenx 10y ago

Reading through the Webpack2 release tags I came across the v2.1.0-beta28 changelog, which mentions: > * add `import()` as Code Splitting construct. It should be used instead of `System.import` when possible. `System.import` will be deprecated in webpack 2 release (removed in webpack 3) as it's behavior is incorrect according to the spec. I was under the impression `System.import` would be the new way to do code splitting and hence supersede `require.ensure()`. After further checking, now it seems like the function-like `import()` will be used instead [1], which is better accepted in browsers than `System.import()`. [0] https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.28 https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.... [1] https://github.com/webpack/webpack/issues/3098 https://github.com/webpack/webpack/issues/3098