4 ms·

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 op

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: [ 'style-loader', { loader: 'css-loader', options: { modules: true } } ] 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.

jchw 7y ago
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.)
devongovett 7y ago
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”.
jessaustin 7y ago
Just try it now, and enjoy how useful it is now. Don't worry about a grim future that may never come to pass.

jchw 7y ago

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

devongovett 7y ago

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”.

jessaustin 7y ago

Just try it now, and enjoy how useful it is now. Don't worry about a grim future that may never come to pass.