
Show HN: Create a personalized and optimized webpack configuration - znaky
http://web.jakoblind.no/webpack-config/
======
purplerabbit
This is a cute tool, but the real solution to this problem is to avoid Webpack
altogether.

Parcel accomplishes everything Webpack does with literally ~0~ configuration.
If you make the switch, it will be the most productive 20 minutes of your
life. (Yes, I am bitter over the MANY hours of my life I've wasted fiddling
with Webpack.)

[https://parceljs.org/](https://parceljs.org/)

~~~
gb_
Parcel is great, but what you're saying is just not true.

Webpack's configuration gives it a great deal of flexibility for working with
many different types of project.

------
royjacobs
Wouldn't it make more sense to have a sort of "Spring Boot" [1] approach for
Webpack, whereby a dependency like React (or a "webpack-react-starter") can
list the features it needs to have enabled and Webpack can then automatically
enable features based on that?

Tooling like this seems a bit backward, in the sense that you're now creating
a tool to create configuration for a tool that runs other tools that~~stack
overflow

[1] [https://docs.spring.io/spring-
boot/docs/current/reference/ht...](https://docs.spring.io/spring-
boot/docs/current/reference/html/boot-features-developing-auto-
configuration.html)

------
jesalg
Nice! Although you might want to update this for Webpack 4.

Like for example, `ModuleConcatenationPlugin` no longer goes in
`config.plugins`. It's now a boolean flag `plugins.concatenateModules`

~~~
crispyporkbites
This is everything you need to know about front end development in one comment

------
komali2
Why file loader and not URL loader?

To be fair this question is coming from a guy with a 4 day old stack overflow
question that essentially amounts to "how the fuck do I use URL loader?"

~~~
guilhermehn
From file-loader's README:

>Instructs webpack to emit the required object as file and to return its
public URL

From url-loader's README:

>The url-loader works like the file-loader, but can return a DataURL if the
file is smaller than a byte limit.

They are interchangeable, do the same thing, but url-loader can generate a
dataUrl if the file is small, like an png/svg icon, so you can save one
request where the latency could be higher than the download time.

I think this feature should be built into file-loader and toggled via loader
option.

~~~
komali2
Oh, I read the docs start to finish, I just can't get the DataURLs to work
lol. You seem like you know what you're talking about, so if you wanna take a
crack at it... [https://stackoverflow.com/questions/49934116/404s-on-some-
im...](https://stackoverflow.com/questions/49934116/404s-on-some-images-from-
webpack-url-loader)

------
tlrobinson
The fact that "lodash-webpack-plugin" and similar exists seems like a symptom
of a larger problem. Why isn't tree shaking [1] good enough?

1\. [https://webpack.js.org/guides/tree-
shaking/](https://webpack.js.org/guides/tree-shaking/)

------
jcolella
Great stuff!. Specially at the beginning, webpack is intimidating and can turn
complex quickly. Wish I had this when I began. Another add-on I would
recommend is the addition of the: \- target: 'node'

for those developer that are using webpack on the backend.

~~~
sebazzz
And encourage yarn instead of npm for both stability, sane defaults, and
performance. :) Small detail though.

------
nailer
SASS (specifically SCSS) support would be good - AFAIK it's the most popular
preprocessor and has been for a few years.

------
rhacker
This is pretty nice. It's funny how all this time on Gulp/Grunt/Npm and a
billion others, and finally we have something that seems to be staying
still...

Now for the feature requests:

* Generally I have webpack.common.js for the common between all environments and webpack.config.js for dev (so the configuration file is named the default thing) and webpack.prod.js for production.

* Typescript checkbox :)

------
cygned
I was thinking about something similar. Making the webpack configuration
accessible using a drag‘n‘drop editor, where you can define environments
(prod, test, etc) and build configuration per environment using building
blocks. JavaScript generation, JSON export (for imports), sharing, etc.

Never had the time to actually start it, though.

------
blackn1ght
This is great! Would be great to see an option for Typescript, and splitting
vendor and application bundles.

------
chewzerita
make = webpack, this tool = autotools

We are going around in a cycle!

~~~
rounce
The difference being that Make is actually usable.

For the silent down-voters: Tell me why the above statement is not true.

~~~
nailer
It's a punctuation heavy format with a bunch of shell code mixed in, which
means projects go from using one language (Python, Ruby, JavaScript etc) to
three (whatever they were using previously plus Make plus shell).

------
jannes
Production mode already defines NODE_ENV. [1] Your usage of DefinePlugin is
redundant in that case. Any reason why you are defining it twice?

[1]:
[https://webpack.js.org/concepts/mode/](https://webpack.js.org/concepts/mode/)

I think for beginners it's great to see what production mode actually does
under the hood, but it shouldn't end up in the final config.

~~~
nobleach
Interesting. I was attempting to compile some bundles over the weekend and was
noticing drastically larger chunk sizes. I realized this was because I had
neglected to specify NODE_ENV=production, and my babel-loader was using my dev
config (which leaves prop-types in the code). Based on your comment, and the
above docs, I shouldn't be seeing what I'm seeing.

~~~
rhinoceraptor
Are you using webpack 3? That change happened in February with webpack 4:

[https://github.com/webpack/webpack/releases/tag/v4.0.0](https://github.com/webpack/webpack/releases/tag/v4.0.0)

------
rounce
Cool tool. Would be great if it was also able to load and manage sections of
existing Webpack configs.

------
verdverm
Check out
[https://github.com/sysgears/spinjs](https://github.com/sysgears/spinjs)

------
Touche
Why do people import PNGs into their JavaScript? That seems pretty weird...
Not a criticism of this tool, which seems quite nice.

~~~
Ambroos
It's a convenience thing. Once you get used to it, it works well. You define a
loader in your webpack config, which then decides what to do with the PNG.

Usually, what happens if you require a PNG is that it passes via url-loader or
file-loader, and optionally image-loader. This'd mean that you'd get a string
(either a full URL or a base64-encoded inline image if it's small enough) that
points to the image, which is optionally minified by image-loader.

If you require CSS or SASS, your webpack loaders will ensure the CSS is
loaded.

~~~
Touche
No, I get what is trying to be achieved, I am just questioning why it is being
done this way and not something much simpler... I would much prefer that my
JavaScript bundler only bundles JavaScript. Converting a PNG into a JavaScript
module through base64 should be pretty trivial, so I'd prefer to do that with
another tool. I do something similar for inlining CSS in my own projects.

~~~
zorkw4rg
You can use one tool to optimize and base64 inline images and another to
compile SCSS and inline it of course. But then you discover that you also want
to optimize and inline images placed within css url() properties so you
implement that feature in your build pipeline, then you discover... you get
the point. Webpack gives you a flexible configurable and extensible way to
handle any such case in any environment which is why everyone uses it for
modern frontend development. I think questioning webpack is like questioning
why people are using dependency injection frameworks in modern java.

~~~
Touche
And then you wind up spending multiple days trying to figure out how to do
something that doesn't quite fit in with what other people have already done.

How many times do we have to learn the same lessons over and over? Small tools
that compose together is _infinitely_ more flexible than any plugin based tool
can possible be.

~~~
fenomas
Importing PNGs to JS is about dependency-wrangling, not task-running.

That is, the point of using webpack isn't that it's the best way to optimize a
bunch of PNGs. The point of webpack is that it can parse your dependency tree
and figure out which PNGs are depended on by a given entry point. If you also
want your PNGs optimized, you can do that with a webpack plugin or a separate
tool, as you like - that's orthogonal to the matter of why it's useful to
import PNGs into JS.

~~~
Touche
Yeah, sorry but I don't buy that. webpack outputs JavaScript bundles, not a
dependency graph. Importing PNGs into JavaScript is only useful if you use a
JavaScript AST to then do something with those imports.

~~~
fenomas
I'm not selling it, and I don't follow what you're disagreeing with. Webpack
_can_ output JS bundles, but it understands dependencies between non-JS assets
as well, and will process any file in the dependency graph any way you like.

As such the point of requiring a PNG into JS (or CSS, or a Vue/React
component, etc) is to tell webpack there's a dependency on it. Then that image
will get pulled in to the build process for entry points that need it, and not
otherwise.

------
manigandham
Scope Hoisting is already part of "production" mode now which enables this and
other optimizations automatically.

------
jschrf
Another poster mentioned this, but I'll reiterate: "avoid Webpack altogether".

ES6 or UMD/AMD please. Please do not subject me to toolchain choices just to
use a lib.

If you're a TypeScript or Babel user, you can share code between backend, web
tier, and native code without Webpack or other complex build tools.

Webpack is unnecessary in most cases.

------
cel1ne
If I had to give one Tipp about front-end development: transition the
buildsystem to gradle and call webpack from there. Also npm can be managed
with it.

Then you can slowly introduce kotlin code, which is way more productive.

In the end I found that writing everything in kotlin, using tachyons for CSS,
the kotlin-minifier for code minification and closure-compiler for
optimization is the most stable way to go.

JavaScript isn't a productive language. Having build-tools in JS just
complicates everything.

