3 ms·
Zero configuration is great until your project requires something that doesn’t fit into the parcel model, at which point it’s simply out of the question, but we
by oefrha 7y ago
Zero configuration is great until your project requires something that doesn’t fit into the parcel model, at which point it’s simply out of the question, but webpack with its myriad configuration options can be bent to your will. I was in that position once, but I can’t recall the details now.
- TheRealPomax 7y agoAs a comment on Parcel, this is kind of a counter productive one. What's the utility of a comment that says "it can't do something, but I don't know what"? If you have the details, those are super valuable to comment with, but if you don't... why comment?
- RHSeeger 7y agoBecause "there exist situations that parcel cannot handle because it doesn't allow configuration". That's a useful thing to know. The fact that the OP can't recall what the situation was also provides a useful piece of information; that it's likely something that is not run into often.
- true_religion 7y agoFrom what I read one of the developers wrote on here, Parcel does allow for configuration. It just doesn’t require it. It’s actually convention over configuration taken to an extreme where it’ll start adding entries to packages.json for you, or wrapping rust code in WASM for you on import.
- TheRealPomax 7y agoExcept that it allows tons of configuration, but is zero-conf by default.
- tyre 7y agoNot every project will get there. I’m building a Firefox extension and I just need to turn ES6 and imports into a bundle. Sometimes that’s all you need
- devongovett 7y agoParcel 2 should help with this a lot. It has a much improved plugin system that allows pretty much everything to be extended and overridden, while still keeping things easy to use by default.
- zamalek 7y agorollup is a good option if you need more config than parcel allows. It takes about 10 minutes to configure rollup correctly, and it's far more sane than webpack.
- weberc2 7y agoI see this all the time with build systems for various languages and projects (as well as for other classes of tools, frameworks, etc). Most of the time you don’t need the more complex tool. Ride out the simpler tool for as long as you can, and only when your product is mature (the time finding market fit is tremendously valuable—don’t waste it on integrating/building the perfect, most future-proof build system) and successful and you have a backlog of features that really do depend on the more complicated solution do you migrate. Ruthlessly trim that backlog for fade dependencies (most of the time the simpler tool really meets the actual requirements, but proponents of the more complex tool will stock the backlog with items that only appear at first blush to depend on the more complex tool). Consider the one-time cost of moving to the more complex tool and the ongoing increased cost of maintaining the more complex tool (and multiply both by 10) and compare those costs to the value of the items in your backlog, making sure to account for opportunity costs (I.e., what else could my team be working on instead of spending time porting and maintaining the more complex tool?). A sign of engineering maturity is knowing the right time frame to plan for relative to your project’s lifecycle. Don’t worry about how your solution will scale when your product is hugely successful and you have Google-scale concerns; focus on getting to next week or next year or whatever timeframe is appropriate for your product’s current level of maturity.