After spending a week with parcel-bundler my parcel configuration files are almost the same size as with webpack. Everything that is not a 'hello-world' situation requires extreme digging and after a while one gets to the same result but with some additional loops introduced by parcel.
Maybe my hopes were too high after getting burned by the extreme complexity and bad architecture of webpack.
My feeling is that parcel is just trying to sweep the dirt under the rug :-)
As a recent convert to Parcel (formerly using webpack), I can confirm that it is working well for me in applications which are substantially more complex than Hello World.
I have Parcel working on projects which have dozens of Typescript files and dozens of dependencies, so nothing massive, but non-trivial anyhow. I have not so far found the need to have much in the way of configuration files under Parcel, it is mostly working "out of the box" except for a bit of fiddling with the public-url command line option.
My iteration turnaround in Webpack (time between saving and seeing the browser change) has been in the range of 10-30 sec whereas under Parcel it has been mostly instantaneous (1-2 sec). This has been a major productivity boost.
Based on my experience, I'm wondering what is keeping anyone using Webpack. I was sort of tentative about Parcel at first since it seemed too good to be true, but so far I have not missed anything from Webpack. Maybe it would be helpful to the Parcel authors if you were clearer about what sort of "extreme digging" or "additional loops" are troubling you.
I have made various large scale projects with Parcel and have never had the need to configure it besides from a simple babel config of a couple lines and sometimes a postCSS config for CSS modules which is also just a one line config.
It would be great to provide more information about your project. As I wouldn't even know how to get close to the size of a webpack config using Parcel.
We are using Parcel at Adobe on a massive project with ~250,000 lines of code and almost no config. In addition, it has made our team able to iterate faster due to the caching and workers, and kept build issues that team members needed to debug to a minimum compared to our prior webpack setup.
I'd also be interested to hear more about your project, @gugurete.
I find HMR too rudimentary:
module.hot.accept, module.hot.accept doesn't allow to intercept children updates... Additionally I can't get around the fact that reloaded modules are evaluated and lose sourcemaps (as far as I can tell), which means you can't put breakpoints and have to resort to manually adding debugger instructions and debugging non-sourcemapped code (wut). Why even supporting sourcemaps in that case?
@elsassph Could you please open separate issues for these two situations? I've run into the HMR api problem as well. Do you know whether HMR with sourcemaps work correctly with webpack?
@mischnic I've raised the issue with the update method: https://github.com/parcel-bundler/parcel/issues/608 - it definitely works with Webpack as each HMR update is loaded as a JS bundle (e.g. a WS message tells the client to load a bundle to replace some modules).
I can raise another ticket for the HMR API problems: https://github.com/parcel-bundler/parcel/issues/2497
Going to close this issue since it was a question that has been answered. Please open separate tickets if you have issues.
Most helpful comment
We are using Parcel at Adobe on a massive project with ~250,000 lines of code and almost no config. In addition, it has made our team able to iterate faster due to the caching and workers, and kept build issues that team members needed to debug to a minimum compared to our prior webpack setup.
I'd also be interested to hear more about your project, @gugurete.