Parcel Bundler is really fun. I would implore people to try it before jumping into too much cynicism because their pursuit for zero configuration has lead to some genius design decisions.
One constant problem with bundlers is how to rewrite the HTML files to match the JS/CSS bundles. You can do all kinds of crap including scripts with regexes, plugins, etc. but what if you could do better?
Put simply, Parcel does better. HTML files themselves can be entries, and they will be compiled such that all of the stylesheets and scripts are compiled, bundled and linked to the HTML file in the output. Now you don’t need to worry about mucking with writing the hash into your HTML.
Parcel isn’t perfect but it makes a great static site gen. Its plugin interface can be slightly cumbersome, but it’s flexible enough that you can abuse it pretty effectively. As an example, I used Parcel to generate some documentation built off of Kaitai Struct KSY files, which are effectively YAML files. I push the KSY data through an HTML template that generates the doc page. It was a lot of fun. You can see it here:
Let's say you want to use CSS Modules, but that's not the default in Parcel. (I don't know if it is, but for sake of discussion, the argument continues). The opinionated default works for some, but not all people. To enable an override, maintainers end up breaking Parcel down into subpackages, and people can pick-and-choose what they want. If that is Parcel's future, what ever did we achieve as opposed to just continuing to use Webpack? In case it's forgotten, this is how you'd enable CSS Modules in webpack:
What could meaningfully be simplified in this configuration? We could get rid of the 'options' object, and spread into the parent object. But then that makes it more difficult for Webpack to statically know if the JSON tree provided is a valid configuration.
I don't see where this leads us. Instead of fragmenting the bundler market, invest in making Webpack better, or move onto to a new problem. There's a limited number of open source contributors out there, and only so much can be built & solved. The end state of a mature Parcel ends up looking basically like Webpack, which sounds like a fragmented, convoluted way of making a questionably impactful contribution to the OSS community.
The trouble I have with Webpack is that everyone has their own snowflake configs, there’s no interoperability, and the config complexity has been bad enough that you could literally have someone working webpack configs fulltime. How many legitimate reasons do you have to have the level of flexibility Webpack provides? How many different TypeScript plugins are necessary? There is a happy medium and Webpack is past it and off the cliff.
To be sure, Webpack is pretty amazing for what it can do, but I consider it harmful for the stated reasons; I do not believe unification on Webpack is helpful because almost literally no two Webpack instances is the same because everyone is repeating basically the same configurations but slightly differently (or radically differently in the pathological end.)
Of course using Parcel doesn’t mean literally no configuration, usually it means standard configuration. All of these softwares work standalone and already do configuration. Need to configure the TypeScript compiler? Use tsconfig! Need multiple tsconfigs? No problem, put them in different folders and you’re good to go.
It’s unlikely you’ll end up with something compromise-free but like dropping to assembler and coding out routines manually the tradeoffs of getting your perfectly ideal output are not necessarily valuable to your fellow devs or your end users. It must be evaluated at some level. For me, Parcel does a good enough job that I trust it to have sane defaults for development and production.
So about your question with CSS modules: you can use .postcssrc as usual, although I do not use (or like, to be honest) CSS modules so I would definitely be the wrong person to comment on how well it is supported.
(Addendum: I anticipate that some will pick up on the duality of saying Webpack configuration is bad but condoning and recommending other configs. To that I would say, it’s all about the details. For one, most of these config files are auto discoverable, whereas for Webpack you gotta know the command invocation. For another, Webpack configs are often executable Javascript whereas most other configs are not used this way. And to be completely honest, the amount of magical configuration you can do in Webpack is hardly ever paralled elsewhere.)
Zero config doesn’t mean non-configurable. You still configure other tools that Parcel runs like Babel, TypeScript, etc. It’s not like create-React-app where if you want to customize anything you cannot (without ejecting). I like to say Parcel has config inference from your actual code, rather than making you declare every minute detail up front. But when you need to change something you can. I wouldn’t call that “opinionated”.
One constant problem with bundlers is how to rewrite the HTML files to match the JS/CSS bundles. You can do all kinds of crap including scripts with regexes, plugins, etc. but what if you could do better?
Put simply, Parcel does better. HTML files themselves can be entries, and they will be compiled such that all of the stylesheets and scripts are compiled, bundled and linked to the HTML file in the output. Now you don’t need to worry about mucking with writing the hash into your HTML.
Parcel isn’t perfect but it makes a great static site gen. Its plugin interface can be slightly cumbersome, but it’s flexible enough that you can abuse it pretty effectively. As an example, I used Parcel to generate some documentation built off of Kaitai Struct KSY files, which are effectively YAML files. I push the KSY data through an HTML template that generates the doc page. It was a lot of fun. You can see it here:
https://packets.pangdox.com/packets/loginservice/server/0002...