16 ms·

Getting Started with Webpack 2

101 points by gregorymichael 10y ago

jitl 10y ago
What is the difference from Webpack 1? This tutorial seems identical to every other Webpack getting started I've read.
- igvadaimon 10y ago
  I guess most of the changes are 'under the hood', but there are some breaking changes in configuration as well. "loaders" => "rules" etc. http://javascriptplayground.com/blog/2016/10/moving-to-webpack-2/ http://javascriptplayground.com/blog/2016/10/moving-to-webpa...
- colinramsay 10y ago
  There's a list from the start of the year here: https://gist.github.com/sokra/27b24881210b56bbaff7 https://gist.github.com/sokra/27b24881210b56bbaff7
  - thelarkinn 10y ago
    Id recommend our newer upgrade guide. https://webpack.js.org/how-to/upgrade-from-webpack-1/ https://webpack.js.org/how-to/upgrade-from-webpack-1/
  - thelarkinn 10y ago
    Id recommend our newer upgrade guide. https://webpack.js.org/how-to/upgrade-from-webpack-1/ https://webpack.js.org/how-to/upgrade-from-webpack-1/
  - deleted 10y ago
    [deleted]
- k__ 10y ago
  I think the biggest addition is ES2015 modules. Webpack now understands them without the need to convert them to commonjs/amd. import works statically (before the JS is run), which allows webpack to make some optimizations. (System.import() is used for dynamic (runtime) imports)
  - vladimir-y 10y ago
    There is also a config validation, which is a good thing.
blowski 10y ago
Interestingly, things seem to be settling down in the JS community. In the past, every time a library lacked a particular feature, the community suddenly abandoned it. At the same time, every new version release had all sorts of horrible breaking changes, that made upgrading a very scary task. Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer.
- xentronium 10y ago
  > Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer. That's exactly why the blog post suggests using yarn instead of npm, isn't it?
  - lucideer 10y ago
    Have you used yarn? Do you know what it is? It's a fully backwards compatible client built on the npm packaging system, using npm's repository, and built in collaboration with the npm team.
    - noir_lord 10y ago
      Its also awesome, I switched when it was on HN a while back and its been amazing. I seldom get excited about JS tools but yarn is an exception.
      - boobsbr 10y ago
        Have you tried PNPM or IED?
    - gcd 10y ago
      It's not quite ready for production yet. There are still some bugs with dev dependencies and private repos that need to be addressed before we can use it.
- 10y ago
kitd 10y ago
1 point of minor interest is that they start by using Yarn, not NPM. Little things like that (esp from a major project like Webpack) can develop into definite trends.
- TeffenEllis 10y ago
  I found the inclusion of Yarn in this tutorial to be misplaced. Adding another step to what is already considered a complex library feels unnecessary. Maybe the author is trying to make Yarn a trend?
  - allendoerfer 10y ago
    > Maybe the author is trying to make Yarn a trend? The JavaScript community makes me a cranky old man, because yarn is even a very good idea and solves actual problems. Still that was the point in the article where I thought "fucking JS hipsters". No time to play with tooling, when there is actual work to do. Especially with other people in your team, whose time costs actual money, I think standardization of dev environments and tools trumps almost every new feature (as long as you were using tools in the first place). I have seen the talk (I believe it was from Instagram), which showed how Webpack could work with shared code and so on, but still: Browserify and Gulp were already working (and I believe can now do the same thing) and even Gulp has only very marginal benefits over Grunt in my opinion. I would love to go a few steps further back, but "installable via npm" is just a crushing argument against Makefiles.
    - shados 10y ago
      Gulp and Grunt were essentially wrong. Using a task runner as an asset pipeline makes no sense. A lot of things, like doing incremental compilation of Sass takes 100+ lines of Gulp crap to do, while it's the default in webpack. Browserify was nice for simple cases, but getting it to do what's needed in a large, real world application was really difficult. Lately it has a lot of those features, but when Webpack became popular, it just didn't. I started using Webpack after doing a length cost/benefit analysis and settling on.....gulp + browserify, because WebPack looked too complicated and people in the team had experience with browserify. After a week of trying to get it to do what we needed, I tried WebPack again and did it in an afternoon. That's when we switched.
alxlu 10y ago
Semi-related: I also found it useful to name the config file webpack.config.babel.js instead of webpack.config.js so I can use ES6 in my Webpack config.
- renke1 10y ago
  Also see interpret [1] which is used by Webpack internally (afaik). For instance, when you name you configuration webpack.config.ts it will be transpiled by TypeScript before being loaded. [1] https://www.npmjs.com/package/interpret https://www.npmjs.com/package/interpret
- shados 10y ago
  No longer really needed. Node 6.X and 7 support pretty much all of ES6 minus imports. Using require instead of import is a very small price to pay to get fast startup time. You can use everything else ES6.
neals 10y ago
I currently use gulp and, over the yars, have found many ways to do my own parsing and smart caching and stuff over, like checking and bumping version numbers, conditional compiling, caching assets etc. I'd hate to loose all that, but I do see the advantages of Webpack. How much control do I have with Webpack though? Can I still write my own hooks?
- intruder 10y ago
  Yes you can hook any kind of plugin up. Can be a simple object that has an 'apply' method exposed that gets passed the compiler.
- noir_lord 10y ago
  That's my concern as well, I use browserify and a simple bash script to do some clever stuff I couldn't reliably do with Grunt, I'd hate to lose the flexibility.
  - intruder 10y ago
    You won't lose any flexibility. See link above regarding plugins.
- the_duke 10y ago
  All of Webpack's core functionality is provided by plugins. By writing your own, you can hook into pretty much everything you could possibly want. https://webpack.js.org/concepts/plugins/ https://webpack.js.org/concepts/plugins/
- shados 10y ago
  The vast majority of anything you'll ever need, even in absurdly complex scenarios, are built in. If you need to do something really wild and weird, the plugin and loader architecture will let you do pretty much anything and hook into nearly everything. We're dealing with a legacy environment here and we have a suite of plugins and loaders to handle non-standard module types, deal with files pulled from CDN at build time, deal with legacy Rails-style script imports, plugins to do all sort of bundle validation, splitting, transforming...really anything goes.
TeffenEllis 10y ago
Now that Webpack has tree shaking, are there still reasons to use Rollup?
- Bahamut 10y ago
  FWIW, Rollup's tree shaking results in a little smaller bundle than Webpack 2's and faster execution speed of the optimized code from testing of using it with ng-bootstrap (an Angular 2 library on top of Bootstrap), but not significant enough for us to justify moving our demo to Rollup. That is just one situation though.
- rich_harris 10y ago
  Rollup's gains come mainly from the way it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle. It's not uncommon to see parse/evaluate time plummet when switching to Rollup because of this, which is often more important than the number of bytes. However Rollup currently lacks a lot of features that make Webpack a good choice for large and complex apps. You can get a feel for the code Rollup generates at http://rollupjs.org http://rollupjs.org.
  - thelarkinn 10y ago
    Rich couldn't have said better !!!!
  - boobsbr 10y ago
    Could you please expand on: > it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle I'm really interested, I got into JS development this year and have no idea of the internals of bundlers/packagers.
- lookupmobile 10y ago
  https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/ https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...
- lookupmobile 10y ago
kozak 10y ago
Webpack 2 is so awesome that I'm really confused why haven't they released it as a non-beta yet. It's way past MVP and has more than enough quality for a non-beta. It looks like the maintainers want it to get perfect and release it "when it's done", and that is so wrong.
- thelarkinn 10y ago
  I can understand your concerns but we made a promise early on that we wouldnt release v2 from beta until our MVP docs milestone is complete. We are just around 90% completion (http://github.com/webpack/webpack.js.org/milestone/1 http://github.com/webpack/webpack.js.org/milestone/1) After that we will release v2. Help always wanted! <3
  - octref 10y ago
    Can you please add some documentation for sourcemap and debugging to the doc? WP 1's sourcemap doc is confusing as hell and WP 2's doc just copied that over. I imagine debugging un-transpiled code with sourcemap is one of the most common use-cases. And I'm not alone if you look at the disqus of WP's doc[0] and a blog by @bebraw[1], one of the guys running webpack.js.org. I even opened an issue[2], I hope it can make into your MVP. [0]: http://survivejs.com/webpack/developing-with-webpack/enabling-sourcemaps/ http://survivejs.com/webpack/developing-with-webpack/enablin... [1]: https://webpack.github.io/docs/configuration.html https://webpack.github.io/docs/configuration.html [2]: https://github.com/webpack/webpack.js.org/issues/273 https://github.com/webpack/webpack.js.org/issues/273
    - thelarkinn 10y ago
      By all means we take PR's as well. Our MVP list is pretty set in stone and we don't want to extend our timeline. However simply by adding the issue to the new docs repo, I'll make sure the information will get prioritized for adding.
- tboyd47 10y ago
  Well, I think it's commendable and shows how much they care about their work. Caution and deliberation seem to be lost virtues in most of the JS universe. Take as much time as you need, Webpack team!
doozler 10y ago
I haven't even got started with Webpack 1 yet!
vladgur 10y ago
We have experienced issues getting sourcemaps support to work in Webpack 2 and had to use Webpack 1 instead. Lack of sourcemaps is a deal killer for us and for any major application IMHO. Has anyone experienced the same and has this been resolved?
- askAwayMan 10y ago
  Which version of the beta? We're using beta 25 currently with babel and source map support.
jagthebeetle 10y ago
Has anyone played with Bazel/Closure? You get dependency management (resolution, pruning) for free from Closure and declarative build targets from Bazel. (Including dependencies on other targets, e.g. non-module-bundle.js) To be fair, I don't think the (publicly) available rule set grants parity with webpack, but the syntax is a lot less gross and the concepts have been there from the start. (Re gross: Instantiation in a config file?)
deleted 10y ago
[deleted]

101 points by gregorymichael 10y ago

jitl 10y ago

What is the difference from Webpack 1? This tutorial seems identical to every other Webpack getting started I've read.

igvadaimon 10y ago
I guess most of the changes are 'under the hood', but there are some breaking changes in configuration as well. "loaders" => "rules" etc. http://javascriptplayground.com/blog/2016/10/moving-to-webpack-2/ http://javascriptplayground.com/blog/2016/10/moving-to-webpa...
colinramsay 10y ago
There's a list from the start of the year here: https://gist.github.com/sokra/27b24881210b56bbaff7 https://gist.github.com/sokra/27b24881210b56bbaff7
- thelarkinn 10y ago
  Id recommend our newer upgrade guide. https://webpack.js.org/how-to/upgrade-from-webpack-1/ https://webpack.js.org/how-to/upgrade-from-webpack-1/
- thelarkinn 10y ago
  Id recommend our newer upgrade guide. https://webpack.js.org/how-to/upgrade-from-webpack-1/ https://webpack.js.org/how-to/upgrade-from-webpack-1/
- deleted 10y ago
  [deleted]
k__ 10y ago
I think the biggest addition is ES2015 modules. Webpack now understands them without the need to convert them to commonjs/amd. import works statically (before the JS is run), which allows webpack to make some optimizations. (System.import() is used for dynamic (runtime) imports)
- vladimir-y 10y ago
  There is also a config validation, which is a good thing.

blowski 10y ago

Interestingly, things seem to be settling down in the JS community. In the past, every time a library lacked a particular feature, the community suddenly abandoned it. At the same time, every new version release had all sorts of horrible breaking changes, that made upgrading a very scary task. Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer.

xentronium 10y ago
> Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer. That's exactly why the blog post suggests using yarn instead of npm, isn't it?
- lucideer 10y ago
  Have you used yarn? Do you know what it is? It's a fully backwards compatible client built on the npm packaging system, using npm's repository, and built in collaboration with the npm team.
  - noir_lord 10y ago
    Its also awesome, I switched when it was on HN a while back and its been amazing. I seldom get excited about JS tools but yarn is an exception.
    - boobsbr 10y ago
      Have you tried PNPM or IED?
  - gcd 10y ago
    It's not quite ready for production yet. There are still some bugs with dev dependencies and private repos that need to be addressed before we can use it.
10y ago

kitd 10y ago

1 point of minor interest is that they start by using Yarn, not NPM. Little things like that (esp from a major project like Webpack) can develop into definite trends.

TeffenEllis 10y ago
I found the inclusion of Yarn in this tutorial to be misplaced. Adding another step to what is already considered a complex library feels unnecessary. Maybe the author is trying to make Yarn a trend?
- allendoerfer 10y ago
  > Maybe the author is trying to make Yarn a trend? The JavaScript community makes me a cranky old man, because yarn is even a very good idea and solves actual problems. Still that was the point in the article where I thought "fucking JS hipsters". No time to play with tooling, when there is actual work to do. Especially with other people in your team, whose time costs actual money, I think standardization of dev environments and tools trumps almost every new feature (as long as you were using tools in the first place). I have seen the talk (I believe it was from Instagram), which showed how Webpack could work with shared code and so on, but still: Browserify and Gulp were already working (and I believe can now do the same thing) and even Gulp has only very marginal benefits over Grunt in my opinion. I would love to go a few steps further back, but "installable via npm" is just a crushing argument against Makefiles.
  - shados 10y ago
    Gulp and Grunt were essentially wrong. Using a task runner as an asset pipeline makes no sense. A lot of things, like doing incremental compilation of Sass takes 100+ lines of Gulp crap to do, while it's the default in webpack. Browserify was nice for simple cases, but getting it to do what's needed in a large, real world application was really difficult. Lately it has a lot of those features, but when Webpack became popular, it just didn't. I started using Webpack after doing a length cost/benefit analysis and settling on.....gulp + browserify, because WebPack looked too complicated and people in the team had experience with browserify. After a week of trying to get it to do what we needed, I tried WebPack again and did it in an afternoon. That's when we switched.

alxlu 10y ago

Semi-related: I also found it useful to name the config file webpack.config.babel.js instead of webpack.config.js so I can use ES6 in my Webpack config.

renke1 10y ago
Also see interpret [1] which is used by Webpack internally (afaik). For instance, when you name you configuration webpack.config.ts it will be transpiled by TypeScript before being loaded. [1] https://www.npmjs.com/package/interpret https://www.npmjs.com/package/interpret
shados 10y ago
No longer really needed. Node 6.X and 7 support pretty much all of ES6 minus imports. Using require instead of import is a very small price to pay to get fast startup time. You can use everything else ES6.

neals 10y ago

I currently use gulp and, over the yars, have found many ways to do my own parsing and smart caching and stuff over, like checking and bumping version numbers, conditional compiling, caching assets etc. I'd hate to loose all that, but I do see the advantages of Webpack. How much control do I have with Webpack though? Can I still write my own hooks?

intruder 10y ago
Yes you can hook any kind of plugin up. Can be a simple object that has an 'apply' method exposed that gets passed the compiler.
noir_lord 10y ago
That's my concern as well, I use browserify and a simple bash script to do some clever stuff I couldn't reliably do with Grunt, I'd hate to lose the flexibility.
- intruder 10y ago
  You won't lose any flexibility. See link above regarding plugins.
the_duke 10y ago
All of Webpack's core functionality is provided by plugins. By writing your own, you can hook into pretty much everything you could possibly want. https://webpack.js.org/concepts/plugins/ https://webpack.js.org/concepts/plugins/
shados 10y ago
The vast majority of anything you'll ever need, even in absurdly complex scenarios, are built in. If you need to do something really wild and weird, the plugin and loader architecture will let you do pretty much anything and hook into nearly everything. We're dealing with a legacy environment here and we have a suite of plugins and loaders to handle non-standard module types, deal with files pulled from CDN at build time, deal with legacy Rails-style script imports, plugins to do all sort of bundle validation, splitting, transforming...really anything goes.

TeffenEllis 10y ago

Now that Webpack has tree shaking, are there still reasons to use Rollup?

Bahamut 10y ago
FWIW, Rollup's tree shaking results in a little smaller bundle than Webpack 2's and faster execution speed of the optimized code from testing of using it with ng-bootstrap (an Angular 2 library on top of Bootstrap), but not significant enough for us to justify moving our demo to Rollup. That is just one situation though.
rich_harris 10y ago
Rollup's gains come mainly from the way it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle. It's not uncommon to see parse/evaluate time plummet when switching to Rollup because of this, which is often more important than the number of bytes. However Rollup currently lacks a lot of features that make Webpack a good choice for large and complex apps. You can get a feel for the code Rollup generates at http://rollupjs.org http://rollupjs.org.
- thelarkinn 10y ago
  Rich couldn't have said better !!!!
- boobsbr 10y ago
  Could you please expand on: > it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle I'm really interested, I got into JS development this year and have no idea of the internals of bundlers/packagers.
lookupmobile 10y ago
https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/ https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...
lookupmobile 10y ago

kozak 10y ago

Webpack 2 is so awesome that I'm really confused why haven't they released it as a non-beta yet. It's way past MVP and has more than enough quality for a non-beta. It looks like the maintainers want it to get perfect and release it "when it's done", and that is so wrong.

thelarkinn 10y ago
I can understand your concerns but we made a promise early on that we wouldnt release v2 from beta until our MVP docs milestone is complete. We are just around 90% completion (http://github.com/webpack/webpack.js.org/milestone/1 http://github.com/webpack/webpack.js.org/milestone/1) After that we will release v2. Help always wanted! <3
- octref 10y ago
  Can you please add some documentation for sourcemap and debugging to the doc? WP 1's sourcemap doc is confusing as hell and WP 2's doc just copied that over. I imagine debugging un-transpiled code with sourcemap is one of the most common use-cases. And I'm not alone if you look at the disqus of WP's doc[0] and a blog by @bebraw[1], one of the guys running webpack.js.org. I even opened an issue[2], I hope it can make into your MVP. [0]: http://survivejs.com/webpack/developing-with-webpack/enabling-sourcemaps/ http://survivejs.com/webpack/developing-with-webpack/enablin... [1]: https://webpack.github.io/docs/configuration.html https://webpack.github.io/docs/configuration.html [2]: https://github.com/webpack/webpack.js.org/issues/273 https://github.com/webpack/webpack.js.org/issues/273
  - thelarkinn 10y ago
    By all means we take PR's as well. Our MVP list is pretty set in stone and we don't want to extend our timeline. However simply by adding the issue to the new docs repo, I'll make sure the information will get prioritized for adding.
tboyd47 10y ago
Well, I think it's commendable and shows how much they care about their work. Caution and deliberation seem to be lost virtues in most of the JS universe. Take as much time as you need, Webpack team!

doozler 10y ago

I haven't even got started with Webpack 1 yet!

vladgur 10y ago

We have experienced issues getting sourcemaps support to work in Webpack 2 and had to use Webpack 1 instead. Lack of sourcemaps is a deal killer for us and for any major application IMHO. Has anyone experienced the same and has this been resolved?

askAwayMan 10y ago
Which version of the beta? We're using beta 25 currently with babel and source map support.

jagthebeetle 10y ago

Has anyone played with Bazel/Closure? You get dependency management (resolution, pruning) for free from Closure and declarative build targets from Bazel. (Including dependencies on other targets, e.g. non-module-bundle.js) To be fair, I don't think the (publicly) available rule set grants parity with webpack, but the syntax is a lot less gross and the concepts have been there from the start. (Re gross: Instantiation in a config file?)

deleted 10y ago

[deleted]