8 ms·

Show HN: Create a personalized and optimized webpack configuration

92 points by znaky 9y ago

rounce 9y ago
Cool tool. Would be great if it was also able to load and manage sections of existing Webpack configs.
jcolella 9y ago
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 9y ago
  And encourage yarn instead of npm for both stability, sane defaults, and performance. :) Small detail though.
jannes 9y ago
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.
- timdorr 9y ago
  Also, DefinePlugin is superseded by EnvironmentPlugin: https://webpack.js.org/plugins/environment-plugin/ https://webpack.js.org/plugins/environment-plugin/
- nobleach 9y ago
  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 9y ago
    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
manigandham 9y ago
Scope Hoisting is already part of "production" mode now which enables this and other optimizations automatically.
blackn1ght 9y ago
This is great! Would be great to see an option for Typescript, and splitting vendor and application bundles.
chewzerita 9y ago
make = webpack, this tool = autotools We are going around in a cycle!
- 75dvtwin 9y ago
  I was just thinking about the 'full circle' today. OSes of the past: Windows, Variations of Unix's, OSes of 2018: Android, IOS, All Varations of Browsers, plus all the old ones --- Cross platform (cross-os) development of the past: nasty (Widget libraries (wxWindows, QT, ... ), os-abstraction libs ) Cross platform development of 2018: nasty still (react-native, xamarin, etc .. ) --- Development pipeline tools of the past: Automake/cmake, make, linker Development pipeline tools of 2018: npm, webpack --- Compiler front ends of the past (things that produce assembler or low-level C or stack-machine codes): various C++ front ends, Eifel, etc Compiler front ends of 2018 (things that spit out javascript): babel (more like macro-assembler), Clojurescript, ReasonML, Fay, Nim .. ,etc --- In current times, we also added Wireframe/Styling tools into our development pipeline (I do not think we had it in the past). Eg Bootstrap and other styling (that are not integrated into 'compile-time-verification' stage of the modern Front-end languages. I realize that above is somewhat front-end-dev oriented, but I think the desire to share 'same language' for front and backend development, causes the blur. I also would add that for data crunching and data distribution (eg CORBA, DRPC) of the past -- we have gained more options, higher quality and free. So I would say this is a material advance for our productivity.
  - rounce 9y ago
    Your comparison is broken. You may as well compare apples to oranges, with the difference being potatoes.
    - vk23 9y ago
      Your phrase is broken. You can easily compare apples to oranges.
      - rounce 9y ago
Touche 9y ago
Why do people import PNGs into their JavaScript? That seems pretty weird... Not a criticism of this tool, which seems quite nice.
- Ambroos 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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.
cygned 9y ago
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.
komali2 9y ago
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 9y ago
  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 9y ago
    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-images-from-webpack-url-loader https://stackoverflow.com/questions/49934116/404s-on-some-im...
verdverm 9y ago
Check out https://github.com/sysgears/spinjs https://github.com/sysgears/spinjs
royjacobs 9y ago
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/html/boot-features-developing-auto-configuration.html https://docs.spring.io/spring-boot/docs/current/reference/ht...
rhacker 9y ago
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 :)
nailer 9y ago
SASS (specifically SCSS) support would be good - AFAIK it's the most popular preprocessor and has been for a few years.
jesalg 9y ago
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 9y ago
  This is everything you need to know about front end development in one comment
cel1ne 9y ago
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.
purplerabbit 9y ago
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/
- Techonomicon 9y ago
  I love parcel, I seem to personally have constant issues with my typescript react project related to breakpoints just completely not working, or when being triggered, mapping to completely other files. I imagine it's a sourcemap issue I may post on the tracker, has anyone seen this themselves?
- gb_ 9y ago
  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.
tlrobinson 9y ago
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/
jschrf 9y ago
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.

92 points by znaky 9y ago

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

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 9y ago
And encourage yarn instead of npm for both stability, sane defaults, and performance. :) Small detail though.

jannes 9y ago

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.

timdorr 9y ago
Also, DefinePlugin is superseded by EnvironmentPlugin: https://webpack.js.org/plugins/environment-plugin/ https://webpack.js.org/plugins/environment-plugin/
nobleach 9y ago
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 9y ago
  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

manigandham 9y ago

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

blackn1ght 9y ago

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

chewzerita 9y ago

make = webpack, this tool = autotools We are going around in a cycle!

75dvtwin 9y ago
I was just thinking about the 'full circle' today. OSes of the past: Windows, Variations of Unix's, OSes of 2018: Android, IOS, All Varations of Browsers, plus all the old ones --- Cross platform (cross-os) development of the past: nasty (Widget libraries (wxWindows, QT, ... ), os-abstraction libs ) Cross platform development of 2018: nasty still (react-native, xamarin, etc .. ) --- Development pipeline tools of the past: Automake/cmake, make, linker Development pipeline tools of 2018: npm, webpack --- Compiler front ends of the past (things that produce assembler or low-level C or stack-machine codes): various C++ front ends, Eifel, etc Compiler front ends of 2018 (things that spit out javascript): babel (more like macro-assembler), Clojurescript, ReasonML, Fay, Nim .. ,etc --- In current times, we also added Wireframe/Styling tools into our development pipeline (I do not think we had it in the past). Eg Bootstrap and other styling (that are not integrated into 'compile-time-verification' stage of the modern Front-end languages. I realize that above is somewhat front-end-dev oriented, but I think the desire to share 'same language' for front and backend development, causes the blur. I also would add that for data crunching and data distribution (eg CORBA, DRPC) of the past -- we have gained more options, higher quality and free. So I would say this is a material advance for our productivity.
- rounce 9y ago
  Your comparison is broken. You may as well compare apples to oranges, with the difference being potatoes.
  - vk23 9y ago
    Your phrase is broken. You can easily compare apples to oranges.
    - rounce 9y ago

Touche 9y ago

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

Ambroos 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.

cygned 9y ago

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.

komali2 9y ago

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 9y ago
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 9y ago
  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-images-from-webpack-url-loader https://stackoverflow.com/questions/49934116/404s-on-some-im...

verdverm 9y ago

Check out https://github.com/sysgears/spinjs https://github.com/sysgears/spinjs

royjacobs 9y ago

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/html/boot-features-developing-auto-configuration.html https://docs.spring.io/spring-boot/docs/current/reference/ht...

rhacker 9y ago

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

nailer 9y ago

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

jesalg 9y ago

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 9y ago
This is everything you need to know about front end development in one comment

cel1ne 9y ago

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.

purplerabbit 9y ago

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/

Techonomicon 9y ago
I love parcel, I seem to personally have constant issues with my typescript react project related to breakpoints just completely not working, or when being triggered, mapping to completely other files. I imagine it's a sourcemap issue I may post on the tracker, has anyone seen this themselves?
gb_ 9y ago
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.

tlrobinson 9y ago

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/

jschrf 9y ago

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.