
Getting Started with Webpack 2 - gregorymichael
https://blog.madewithenvy.com/getting-started-with-webpack-2-ed2b86c68783#.diw20huhm
======
blowski
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.

~~~
tboyd47
I'm still skeptical. Webpack is one of the saner ones. Many JS libraries are
still doing break-everything major version releases- Babel and Angular come to
mind.

~~~
whostolemyhat
That's what a major version is supposed to signify though, isn't it? Most
JS/NPM-based projects use semantic versioning, so a major version update means
breaking/backwards-incompatible.

~~~
tboyd47
Even if it's communicated correctly, it's still a hassle.

~~~
whostolemyhat
Are you complaining that things get updated? You don't have to use the
absolute latest versions of everything, you can still use older versions if
you want.

~~~
jameskilton
Caring about upgrade paths is super important to the longevity of a project.
See: Python 3 vs Ruby 2 adoption.

Taking the mentality that "I can break everything and just bump the major
number" will lead to a project that either 1) is no longer is used by many
people or 2) is a maintenance hell because people are staying on old versions
and asking for bug fixes and improvements.

------
neals
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?

~~~
noir_lord
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
You won't lose any flexibility. See link above regarding plugins.

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

~~~
colinramsay
There's a list from the start of the year here:

[https://gist.github.com/sokra/27b24881210b56bbaff7](https://gist.github.com/sokra/27b24881210b56bbaff7)

~~~
thelarkinn
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/)

------
vladgur
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
Which version of the beta? We're using beta 25 currently with babel and source
map support.

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

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

~~~
boobsbr
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.

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

------
kozak
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
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
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/enablin...](http://survivejs.com/webpack/developing-with-
webpack/enabling-sourcemaps/)

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

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

~~~
vladimir-y
> Gulp and Grunt were essentially wrong.

They were not wrong, but they do a general automation (and sometimes it's
needed), just a task runners and a wrong thing was to use them for web
building automation collection scattered over the internet stuff together into
the complex framework. So every team or project had own framework, which means
no standard, and that's a bad thing. Webpack allows to defined a needed
behavior in a kind of declarative way since it has a structure.

------
jagthebeetle
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?)

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

