Show HN: Create a personalized and optimized webpack configuration
web.jakoblind.no
web.jakoblind.no
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.)
I imagine it's a sourcemap issue I may post on the tracker, has anyone seen this themselves?
Webpack's configuration gives it a great deal of flexibility for working with many different types of project.
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...
Like for example, `ModuleConcatenationPlugin` no longer goes in `config.plugins`. It's now a boolean flag `plugins.concatenateModules`
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?"
>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.
for those developer that are using webpack on the backend.
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 :)
Never had the time to actually start it, though.
We are going around in a cycle!
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.
To stay on topic what makes you think that the comparison is flawed?
What makes webpack uncomparable to make?
How can android / browsers not be compared to windows / linux?
Why can't make be used to pack web applications?
...
For the silent down-voters: Tell me why the above statement is not true.
I've been using Make for 15 years across multiple programming languages. It's a small, dependable, and simple utility.
I've been painfully slogging through Webpack configs for 4 years. I dread dealing with it every single time I open the file.
The newer versions of WP is surprisingly simple to set up.
[1]: 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.
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.
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.
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.
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.
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.
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.