Parcel – Fast, zero-configuration web application bundler(parceljs.org)
parceljs.org
Parcel – Fast, zero-configuration web application bundler
https://parceljs.org/
212 comments
This is somewhat true. I was working at Adobe while building Parcel in my spare time at first, mostly to improve build perf of an app at work. After it launched and we used it internally for a while, Adobe finally started sponsoring the project.
Now, Parcel 2 has a core team of 9 active members from various companies including Adobe, Atlassian, and Eventbrite. We also receive funding on Open Collective which we distribute to a couple independent members of the team who aren’t already sponsored by a company. Definitely a multi-company effort at this point! :)
Now, Parcel 2 has a core team of 9 active members from various companies including Adobe, Atlassian, and Eventbrite. We also receive funding on Open Collective which we distribute to a couple independent members of the team who aren’t already sponsored by a company. Definitely a multi-company effort at this point! :)
Just curious how these things go, are there the odd people in these companies full-time working on a sponsored tool or framework, or is this people on a team that's using these, finding some time at the end of a sprint to contribute (like 10% time), or some other model?
Usually it's one or two people using their spare time to eventually get something good enough to work on work time occasionally unless it's 100% aligned with the company goals (e.g. a company like zeit or gatsby)
Parcel is good (and I use it), but it's likely if someone had pitched it internally I'd bet someone would have said "Webpack is good enough for us". At least that's how it would have gone at the places I've worked at.
Parcel is good (and I use it), but it's likely if someone had pitched it internally I'd bet someone would have said "Webpack is good enough for us". At least that's how it would have gone at the places I've worked at.
Originally that's how it happened: I was working on a product and frustrated with build perf, so built parcel in my spare time to scratch that itch. Eventually convinced the team to adopt it.
Atlassian has 2 full time engineers working on Parcel now though, so they've made a pretty big investment.
Atlassian has 2 full time engineers working on Parcel now though, so they've made a pretty big investment.
wild. didn’t realize that Adobe was behind Parcel.
Love it, but it isn’t all that often that it’s truly zero-conf. regardless, it almost always seems easier than Webpack.
Except, that it is not really zero configuration and you still have to figure out some settings for getting source maps to be referenced correctly.
It is blazing fast though and much less a pain to set up than webpack. Every time I have to touch webpack configurations I think: "Oh no, not that stuff again ..." and it will take time to get it exactly the way I want or even requires to load additional helper modules from NPM. Ugh.
It is blazing fast though and much less a pain to set up than webpack. Every time I have to touch webpack configurations I think: "Oh no, not that stuff again ..." and it will take time to get it exactly the way I want or even requires to load additional helper modules from NPM. Ugh.
Hehe. There's always been some confusion about the term "zero configuration". To us, it's always meant no config needed to get started (and for the 90% case), but possible to configure later if needed. :)
That is the definition for convention over configuration. Zero Config means no configuration, more like what harp.js does.
parcelrc would be a nice addition.
Coming in Parcel 2! :) https://github.com/parcel-bundler/parcel/blob/v2/packages/co...
That’s awesome. Been eagerly awaiting this release
How did you get sourcemaps working? My limited search of solutions just points to a lot of issues where a maintainer says “could not reproduce the issue” and closes it.
What's not working for you?
For me sourcemaps is just working (I mainly use Parcel with TypeScript, so Parcel takes TS -> ES6+ -> JS -> Bundle). What's your path?
For me sourcemaps is just working (I mainly use Parcel with TypeScript, so Parcel takes TS -> ES6+ -> JS -> Bundle). What's your path?
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:
https://packets.pangdox.com/packets/loginservice/server/0002...
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...
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.
[ '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.
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.)
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”.
Just try it now, and enjoy how useful it is now. Don't worry about a grim future that may never come to pass.
One cool thing about parcel is that you can use es import syntax to "import" stuff from rust modules. It will then automagically do all the wasm interfacing for you during the bundling process. Wow!
You can also import stuff from wasm modules too of course, but I like the magic of "importing rust into JavaScript". It seems like a great way for someone like me, who wants to learn, to use rust into a simple web project without worrying too hard about wasm.
https://parceljs.org/rust.html
You can also import stuff from wasm modules too of course, but I like the magic of "importing rust into JavaScript". It seems like a great way for someone like me, who wants to learn, to use rust into a simple web project without worrying too hard about wasm.
https://parceljs.org/rust.html
You can do that with webpack, that feature is not specific to parcel https://github.com/rustwasm/wasm-pack
Sure. With Webpack you can find a Medium article that tells you how to install and configure a plugin, run into places where things changed because of major webpack versions and plugin ecosystem evolution, and after enough digging you might get it working.
In Parcel you include the rs file. Seriously.
In Parcel you include the rs file. Seriously.
This sums up my experience with webpack quite nicely. It doesn't help that boilerplates like CRA are so ergonomic in terms of saving startup time in other places as well, because this means I really need to have a good reason to manually fuck with webpack. This combined means every time I finally end up looking at webpack, my knowledge of it is super rusty. I've definitely been side-eyeing parcel for a while
[deleted]
If 9 seconds is "Blazing fast", I wonder how would something like Elm experience of usually building stuff in around 0.2s be named. I think 9s is an embarrassing number, especially when you mostly compile JS to JS.
Parcel is great, but I would avoid using it again due to the sheer number of dependencies (730 packages!)[1]. Webpack has the same problem[2], depending on 342 packages. Rollup is the best one on this regard, depending only on 3 packages.
[1]: http://npm.anvaka.com/#/view/2d/parcel
[2]: http://npm.anvaka.com/#/view/2d/webpack
[1]: http://npm.anvaka.com/#/view/2d/parcel
[2]: http://npm.anvaka.com/#/view/2d/webpack
We do include a lot more features out of the box than other tools, so this makes sense to some degree. In Parcel 2, we're splitting up the core into lots of small plugin packages so you can only install what you need. The Parcel 2 core is tiny - only a handful of dependencies.
Should a bundler really include all those features though? All I want out of a bundler is to bundle. As soon as it starts doing transforms, we end up with applications that only work with that bundler.
As a user of Parcel, I definitely want it. I wrote my Elm program, found myself wondering what the best tool would be to automate the running of elm make, bundling, not to mention transpiling the small amount of ES6 and sass I had in there as well. Less than five minutes later I have parcel installed with no config and it all just works with parcel start, god bless.
If you just want to bundle JS files, then Parcel probably isn't the tool you want.
If you're building a modern web app, you're likely using more than just JS files. The compilation target is complex, and there's room for more optimizations when the bundler is aware of the app as a whole.
If you're building a modern web app, you're likely using more than just JS files. The compilation target is complex, and there's room for more optimizations when the bundler is aware of the app as a whole.
This is the stance that Browserify took, and a stance I really liked myself. But the community overwhelmingly voted for Webpack.
If you want to just bundle, use rollup or browserify. They are pure bundlers based around ES Modules and CommonJS respectively.
Parcel is here because most people don’t need to just bundle but also a whole pipeline for optimization and extended browser support (Babel)
Parcel is here because most people don’t need to just bundle but also a whole pipeline for optimization and extended browser support (Babel)
It would be nice to auto-detect needed features and automatically link those packages. Then the guesswork for knowing which packages to include will be minimal.
Parcel has that, partially. If you add a .vue file it adds the Vue packages to package.json, same with Typescript.
Parcel by itself is small, but it could potentially require a lot less packages by default if it did that with other large dependencies: Babel, SVGO, CSS Nano, PurgeCSS/UnCSS, PostHTML, which are not required if you don't use Parcel to bundle JS/SVG/CSS/HTML.
Parcel by itself is small, but it could potentially require a lot less packages by default if it did that with other large dependencies: Babel, SVGO, CSS Nano, PurgeCSS/UnCSS, PostHTML, which are not required if you don't use Parcel to bundle JS/SVG/CSS/HTML.
Yep, we’re definitely going this direction with Parcel 2. :)
[deleted]
Why would the dev footprint matter? whether it depends on 10 or 10,000 packages, if you managing your project sensibly, `parcel` is a build-only dependency, installing only on your machine, and on CI instances (most of which can take advantage of cached depenency lists already anyway).
Those dependencies, many probably written by unknown authors with 0 stars on github, have complete access to your computer and can execute arbitrary code. Even though it shouldn't affect production, that's still a big problem for your own machine.
To put it another way, would you willingly download and execute 730 programs from unknown authors on your computer?
To put it another way, would you willingly download and execute 730 programs from unknown authors on your computer?
This is a systemic problem with JS dev in general. I know of zero projects that keep the number of dependencies low enough to enable manual audit. Pretty much everyone out there is blindly installing hundreds, and often thousands, of packages, no matter what setup they choose.
Spitballing...couldn't there be a cloud-based Bundler as a Service? Mind you, there's a risk in letting someone else "see" your code, having 700+ applications of unknown origin isn't any better.
If the host of the BaaS could be trusted, and they constantly vetted all packages, isn't that possibility less risky?
If the host of the BaaS could be trusted, and they constantly vetted all packages, isn't that possibility less risky?
Especially with minified JS, how would you be sure, that you get a minified version of your actual code and not one, which does something else additionally, which you might not want?
Not saying, that running 700+ apps is better, just noting, that bundling as a service might not be a perfect solution either.
Not saying, that running 700+ apps is better, just noting, that bundling as a service might not be a perfect solution either.
What about bundling in a local VM or docker container?
I believe there could be some malicious code added to the bundle by these dependencies regardless of where it is being run
I was mostly addressing the part regarding malicious dependencies gaining access to your local filesystem.
If we are talking about the final bundle itself being compromised, there is not really a technical solution to that other than not using dependencies.
If we are talking about the final bundle itself being compromised, there is not really a technical solution to that other than not using dependencies.
I might be missing something here, but that cloud based service would either need to run webpack, roll-up, or parcel on the files you send them, or write a new application from scratch (without dependencies). I guess businesses are gonna business but if you're writing that application anyway why not just release it for devs to run on their own machines and ci servers?
Yes. Same flow/process. The difference is, the service provider vets the packages. Certainly, given the risks, there's a market at the enterprise level. Sec for them is real.
That's a universal dependency problem, and is why you're advised to always run a not-a-throwaway-project with vulnerability monitors. Heck, if you use something like Github, you even get that for free these days.
More dependencies mean greater attack surface as we’ve seen in npm. I agree with your view, but there is a reason to prefer fewer deps even in dev.
Less code, less bugs.
This is especially true as projects age; i recently ran into yet another bug installing dependencies for a rails app, because of a patch-version change on a small library had a bug that manifested with our otherwise old/legacy stack.
I could see a similar situation for projects stuck on older version of node, lodash or whatever, where some tiny component break everything.
Its always fun when you have a known good build, make a change and trigger an error - only to realize the error is in your build system/dependency graph due to someone else doing testing on a different subset of versions than you need - not due to the change you just did.
I could see a similar situation for projects stuck on older version of node, lodash or whatever, where some tiny component break everything.
Its always fun when you have a known good build, make a change and trigger an error - only to realize the error is in your build system/dependency graph due to someone else doing testing on a different subset of versions than you need - not due to the change you just did.
That sounds like you forgot to peg your version dependencies, though. No matter the age of your code, proper version pegging in an ecosystem that does not allow version deletions (something npm learned the hard way, but amazingly, something pypi allows to this day) ensures that things don't break until you intentionally bump versions.
I generally expect patch version bumps (0.8.0 to 0.8.1)to give me fixes I want, without regressions or new bugs.
Note that there aren't a lot of ecosystems where everyone follows semver rules. Even on the npm registry, patch version bumps can still very much break your code because there's no validation during publication. It's still on you to make sure you have tests set up that run when code or dependencies change, even for something as simple as a patch version bump.
Although specifically to your example of 0.8.0 to 0.8.1: that's exactly the kind of version that semver guarantees is not safe: major version 0 is the "unstable" version, and the minor/patch rules do not apply to it (see https://semver.org/#spec-item-4).
Although specifically to your example of 0.8.0 to 0.8.1: that's exactly the kind of version that semver guarantees is not safe: major version 0 is the "unstable" version, and the minor/patch rules do not apply to it (see https://semver.org/#spec-item-4).
Parcel, webpack and others are build tools very similar to compilers. They take code, process all of it and spit something out, something that would be distributed to the end users.
Now here is a very old and fascinating story - https://www.quora.com/What-is-a-coders-worst-nightmare/answe... and it's base, the seminal Ken Thompson Hack - https://wiki.c2.com/?TheKenThompsonHack
Sounds dangerous? It should. It is very easy to inject code in a small unknown dependency out of those thousands and effectively recreate the Ken Thompson hack.
Now here is a very old and fascinating story - https://www.quora.com/What-is-a-coders-worst-nightmare/answe... and it's base, the seminal Ken Thompson Hack - https://wiki.c2.com/?TheKenThompsonHack
Sounds dangerous? It should. It is very easy to inject code in a small unknown dependency out of those thousands and effectively recreate the Ken Thompson hack.
Sure, but let's also take the code hosting situation into account: npm now comes with security audits during install, and github now comes with free dependency vulnerability monitoring. While "fewer deps means fewer vectors" is true, the security landscape has changed an unusual amount, and for the better, since that article was written.
> npm now comes with security audits during install, and github now comes with free dependency vulnerability monitoring
Ultimately, these are solutions to problems that should not exist in the first place.
Ultimately, these are solutions to problems that should not exist in the first place.
This one is even better (scifi, but possible to execute by humans).
https://www.teamten.com/lawrence/writings/coding-machines/
https://www.teamten.com/lawrence/writings/coding-machines/
[deleted]
This is my primary issue with just about every sizable library in the JS ecosystem. All I need to do is concatenate some files and convert ES6 and now I have 700+ packages in my node_modules folder.
I wish core JS had more functionality built in to alleviate the need for all these tiny packages.
I wish core JS had more functionality built in to alleviate the need for all these tiny packages.
If you don't need to extract CSS that is imported in JS files (which I dislike anyway), you can just use the TypeScript compiler that will work with ES6 modules and transpire into as low as ES3. And it has 0 dependency.
Unfortunately it does not bundle to usable file for browsers, but SystemJS and AMD, and then we are back to RollUp or Parcel or Webpack.
One day...
Unfortunately it does not bundle to usable file for browsers, but SystemJS and AMD, and then we are back to RollUp or Parcel or Webpack.
One day...
My experience with Rollup was cool before I tried to import an image and use React hot reloading...
Do you have a breakdown of the impact of those numbers? What functionality differences do you get thanks to those dependencies (more compatibility, smaller bundle size maybe)? What are the concrete downsides of those dependencies (how much space or bandwidth do they take for for devs, are there known security or stability concerns)? It’s hard to make a judgement off of just the dependency numbers.
Maybe you are interested in a real-world comparison, where you'd see that the solutions always pretty much tend to go in the triple digits (# dependencies).
It's the old tradeoff: Configuration (+ installation of multiple plugins, which may all break individually) vs. one system that already just works.
I guess Parcel 2 will be better in that regard.
It's the old tradeoff: Configuration (+ installation of multiple plugins, which may all break individually) vs. one system that already just works.
I guess Parcel 2 will be better in that regard.
Parcel is great, 99% of the time I'm doing frontend development I just want my build tool to convert Sass/Less/JSX/Babel code to whatever browsers support. It's nice to just source a .sass or .js file and have Parcel figure out the rest.
Has anyone used Parcel and Webpack and still prefers Webpack?
Has anyone used Parcel and Webpack and still prefers Webpack?
I switched from Parcel to Webpack after lots of bugs and issues. Parcel 1 had lots of tiny things that annoyed me (source maps never worked, it broke a lot when pulling from git), and the team is no longer fixing Parcel 1 issues. However, Parcel 2 literally didn't work for me:
https://github.com/parcel-bundler/parcel/issues/3690 https://github.com/parcel-bundler/parcel/issues/3691 https://github.com/parcel-bundler/parcel/issues/3696
So I switched to webpack. The configuration was miserable, but after I got it working, it seems to be OK. It's actually faster than Parcel, and a lot more stable.
https://github.com/magcius/noclip.website/blob/master/webpac...
Not to mention that I had a few issues with Parcel trying to be "too smart" for me. It would automatically try to hot reload, but my app wasn't designed for that, so it would break hard rather. The workaround was throwing an Error in the hot reload handler.
https://github.com/parcel-bundler/parcel/issues/3690 https://github.com/parcel-bundler/parcel/issues/3691 https://github.com/parcel-bundler/parcel/issues/3696
So I switched to webpack. The configuration was miserable, but after I got it working, it seems to be OK. It's actually faster than Parcel, and a lot more stable.
https://github.com/magcius/noclip.website/blob/master/webpac...
Not to mention that I had a few issues with Parcel trying to be "too smart" for me. It would automatically try to hot reload, but my app wasn't designed for that, so it would break hard rather. The workaround was throwing an Error in the hot reload handler.
I'm hesitant to try parcel, and generally use webpack w/ laravel-mix, even in node projects simply because it's a pretty decent 'starting' point for webpack config, and I can override the config anyway I want when I need to which isn't too often.
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.
I 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.
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.
Parcel 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.
As 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?
Because "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.
From 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.
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.
Except that it allows tons of configuration, but is zero-conf by default.
Not 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
Sometimes that’s all you need
rollup 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.
I use both.
Parcel has some bugs that webpack doesn't since the latter has much better funding and corporate support from Facebook.
Parcel has some bugs that webpack doesn't since the latter has much better funding and corporate support from Facebook.
Yeah, I actually was very excited to use Parcel until I ran into a tree-shaking bug on my project that broke the generated bundle. I ended up switching to rollup instead, since although you still had to configure it, there were many less times than webpack where things misbehaved for some non-obvious reason.
Still, I dig what the project is going for, and intend to try out Parcel 2 when it becomes stable.
Still, I dig what the project is going for, and intend to try out Parcel 2 when it becomes stable.
Can you edit in some links to those bug's issues on the parcel repo?
> and corporate support from Facebook
Huh? Aren’t you confusing webpack with prepack?
Huh? Aren’t you confusing webpack with prepack?
I’ve found that every time I start a project with parcel, I eventually want to change something about the Babel config and end up switching to webpack: once I was familiar with it, configuring webpack wasn’t all that bad
Parcel works with normal .babelrc configs the same way as webpack or other tools. Curious what you couldn't change.
I use Parcel for very small projects but vastly prefer Webpack for my "day job". On large projects it's so useful to have full control over your build pipeline. I've written a few custom loaders and plugins that we use for things like managing legacy code and dealing with oddities of our deployment system. I spent two days learning Webpack a few years ago and that has paid dividends ever since. It really is a beautiful tool but most people just want to start writing code and don't really care about the minutiae.
Switched to Rollup.
Can you elaborate why?
I tried it in the past (maybe a year ago) and just 2 weeks ago, too. The experience I had was aweful. Pretty much nothing was working. Maybe I am too biased from Parcel and I got disappointed when even simple things such as starting with an HTML file as root module does not work, or when importing CSS does not work, or when using TypeScript does not work.
What I particularly disliked is that it cannot even cope with the standard stuff that I throw at it. CommonJS modules (only the standard...)? You need a plugin. Not only that: I had to specify what modules I wanted to include and what they export. Do you know a way around all these wholes or is your solution always pretty much self-contained?
I tried it in the past (maybe a year ago) and just 2 weeks ago, too. The experience I had was aweful. Pretty much nothing was working. Maybe I am too biased from Parcel and I got disappointed when even simple things such as starting with an HTML file as root module does not work, or when importing CSS does not work, or when using TypeScript does not work.
What I particularly disliked is that it cannot even cope with the standard stuff that I throw at it. CommonJS modules (only the standard...)? You need a plugin. Not only that: I had to specify what modules I wanted to include and what they export. Do you know a way around all these wholes or is your solution always pretty much self-contained?
The one killer feature of rollup (which parcel also gets right) is sensible and usable sourcemaps. Webpack does not deal with using Vue SFCs and TS very well, you end up with 4-5 [almost empty] files in the browser per file on-disk and often the file with the actual source is missing. You have to hunt down the correct file and pray that it is their every time you wish to set a breakpoint. I've burned days in the past trying to figure out a workaround for the unusability of sourcemaps in Webpack. Webpack has tons of knobs and levers to configure sourcemaps, but none that do what I assume most people want (a single sourcemapped file in the browser).
Parcel and Rollup do the right thing 90% of the time (requiring only tweaking the path for the 10% remainder) with a single boolean configuration value.
Parcel and Rollup do the right thing 90% of the time (requiring only tweaking the path for the 10% remainder) with a single boolean configuration value.
I used wepback before, and on every project it horrible to configre Webpack. A waste of time for me.
Tried some other packager and ended with Parcel and Rollup. I like Rollup, i can not say why i prefer it over parcel. Both are better, easier, faster then webpack.
Tried some other packager and ended with Parcel and Rollup. I like Rollup, i can not say why i prefer it over parcel. Both are better, easier, faster then webpack.
Thanks - yeah I fully agree!
Ah, the classic build tool evolution cycle!
1. Become frustrated with complex build tool
2. Write a new tool that is dead simple, opinionated (your opinions), convention over configuration, etc
3. Post to HN
4. Achieve adoption
5. As more people use the tool, feature creep ensues
6. In order to satisfy diverse use cases, make everything modular and configurable!
7. Tool slows and becomes impossible to manage
8. GOTO 1.
1. Become frustrated with complex build tool
2. Write a new tool that is dead simple, opinionated (your opinions), convention over configuration, etc
3. Post to HN
4. Achieve adoption
5. As more people use the tool, feature creep ensues
6. In order to satisfy diverse use cases, make everything modular and configurable!
7. Tool slows and becomes impossible to manage
8. GOTO 1.
You’re right, this is happening to some degree with Parcel. Our aim with Parcel 2 is to open up the plugin system to allow more extensibility while keeping it as simple as possible to use out of the box. This is accomplished through a very well defined plugin system with explicit extension points for each step of the build pipeline (not the Wild West of extensibility like other tools), and a good default configuration that you can extend or override as needed with a simple JSON config format. The result is that you get everything Parcel 1 could do and more out of the box, but you can easily change or extend Parcel 2 with more features specific to your app if you need to.
We’ve been working on Parcel 2 for almost 2 years now (~1 year in design, another in development) and I think it strikes a pretty good balance. I’m excited to see what the community does with it! :)
We’ve been working on Parcel 2 for almost 2 years now (~1 year in design, another in development) and I think it strikes a pretty good balance. I’m excited to see what the community does with it! :)
Can the configuration have strong types (via TypeScript or similar) pretty pretty please? One of my main frustrations with webpack is the undocumented, unpredictable, unspecified config file format that seems to have no rhyme or reason, which you must often change with every new plugin you add.
Yep! I think we should be able to publish a JSON schema definition that editors like vscode can use to provide autocomplete etc.
That’s not strong typing, that’s automated (and not necessarily up to date) documentation :(
Is there another way to provide strong types for a JSON file?
I believe vscode uses schemas from http://schemastore.org/ for many config files already.
I believe vscode uses schemas from http://schemastore.org/ for many config files already.
Yep, a schema would work fine for this (and you can generate it from types)
You can test them locally using vscode using the "$schema" field on the root obj, here's an example PR doing all that: https://github.com/danger/peril/pull/281
You can either have users add that schema reference in the JSON (throw it in the template) or ship a vscode extension which connects them
You can test them locally using vscode using the "$schema" field on the root obj, here's an example PR doing all that: https://github.com/danger/peril/pull/281
You can either have users add that schema reference in the JSON (throw it in the template) or ship a vscode extension which connects them
If you define the types in TS, you can use https://github.com/YousefED/typescript-json-schema to automatically generate a JSON schema from it. That way, configurations can be specified either in an executable JS module or in a JSON file.
Yep, we’ll definitely use a tool like that. We already have types in Flow for all of Parcel 2, so should be possible to do something similar.
It wasn't clear until now that the configuration is done through JSON rather than being configurable through code (i.e TypeScript).
Urgh, JSON for configuration. That's going to be horrible.
Urgh, JSON for configuration. That's going to be horrible.
JSON is much more static and predictable for configuration. Config through a real programming language was a mistake that many tools made unfortunately. Static configuration has several nice properties including cacheability and simplicity that cannot be guaranteed in a full programming language. Just look at webpack.config.js for an example of the opposite.
That's all totally awesome and cool, right up until the moment you want to add a comment to your configuration. Because you know, it's configuration, and that requires comments.
Quite a few tools went from just JSON configuration files to supporting both .js and .json.
Regarding caching, perhaps I'm mistaken but what's the issue there? Two JSON documents can be equivalent with different bytes so you need to re-parse the configuration file fairly often anyway. So what's the difference with just re-evaluating a .js configuration file and caching the output? If someone wants to put a `if (random() > 0.1)` statement in their config then that's their problem.
Quite a few tools went from just JSON configuration files to supporting both .js and .json.
Regarding caching, perhaps I'm mistaken but what's the issue there? Two JSON documents can be equivalent with different bytes so you need to re-parse the configuration file fairly often anyway. So what's the difference with just re-evaluating a .js configuration file and caching the output? If someone wants to put a `if (random() > 0.1)` statement in their config then that's their problem.
We use json5, which allows comments.
You cannot statically cache the results of a .js file - it might include objects or functions that cannot be serialized, and might cause side effects that parcel cannot know about. If we supported .js config files, we would have to intentionally limit what you can return to basically just JSON, so you wouldn’t get much benefit from it and it would be hard to enforce.
You cannot statically cache the results of a .js file - it might include objects or functions that cannot be serialized, and might cause side effects that parcel cannot know about. If we supported .js config files, we would have to intentionally limit what you can return to basically just JSON, so you wouldn’t get much benefit from it and it would be hard to enforce.
Oh right! Thank you for your clarifying comments, this does sound pretty interesting. Sorry for being flippant before.
Looking forward to reading about the new release!
Looking forward to reading about the new release!
jsonp
All configuration is static. The advantage of using JS (or a language file) is that you run it to generate the appropriate config for that moment and environment.
That need won't ever go away, so not supporting means we're back to users generating their own "static" config files in a separate process. Nothing has been saved, only made more complicated.
That need won't ever go away, so not supporting means we're back to users generating their own "static" config files in a separate process. Nothing has been saved, only made more complicated.
I feel that pain, yeah.
On the other hand, at least the error messages are often helpful with Webpack.
While I think this cycle is real, I feel Parcel has done a good job in general being very careful about becoming what they aimed to avoid. Sure, Parcel has some feature creep, but I’d say they have pretty much completely accomplished the goal of removing the need for complicated Webpack configs.
Is it practical? Apparently it’s practical enough that it can compile Monaco Editor, which can either use a fairly hefty Webpack config, or no config at all with Parcel.
Is it practical? Apparently it’s practical enough that it can compile Monaco Editor, which can either use a fairly hefty Webpack config, or no config at all with Parcel.
While it is a cycle, it isn’t necessarily a bad cycle. With this cycle there is constant innovation to meet changing needs; there is always some new product addressing the shortcomings of the incumbent competitor.
One bad thing about the cycle is we never get to stop dealing with the problem. Because we’re in a cycle of destruction and renewal, applications rot as the infrastructures under them become incompatible.
Where people stopp trying to make “pluggable systems” and “platforms” and instead tried to actually solve problems with finality, and to create procedural interfaces that cover a clear cone of responsibility, the result is mature libraries that stop changing, and become bedrock under applications.
I won’t say it’s “bad” not to strive for that. It is a unique challenge you may or may not wish to tackle.
Where people stopp trying to make “pluggable systems” and “platforms” and instead tried to actually solve problems with finality, and to create procedural interfaces that cover a clear cone of responsibility, the result is mature libraries that stop changing, and become bedrock under applications.
I won’t say it’s “bad” not to strive for that. It is a unique challenge you may or may not wish to tackle.
One person’s bedrock is another person’s pile of anachronisms, cruft, and poorly designed abstractions held together with duct tape.
Bedrock in this sense is small tools that you either build on or you don’t.
What you’re describing is different:
“Abstractions” are by definition unnecessary, they are imaginary things which imperfectly model of some real things underneath. They are contrasted with control systems, which strive to manipulate those things without any metaphor.
“Cruft” is items which you don’t need that are bundled with items you do need. It is contrasted with tools that are easy to just not use at all.
I don’t know what anachronism means in this context.
I’m not saying it’s easy to make tools that are neither abstract, nor bundled with unrelated things. Just that it is a place you can aim for.
I disagree with your notion that abstractions and cruft are inevitable. They’re not inevitable, they are encouraged in the present development climate.
What you’re describing is different:
“Abstractions” are by definition unnecessary, they are imaginary things which imperfectly model of some real things underneath. They are contrasted with control systems, which strive to manipulate those things without any metaphor.
“Cruft” is items which you don’t need that are bundled with items you do need. It is contrasted with tools that are easy to just not use at all.
I don’t know what anachronism means in this context.
I’m not saying it’s easy to make tools that are neither abstract, nor bundled with unrelated things. Just that it is a place you can aim for.
I disagree with your notion that abstractions and cruft are inevitable. They’re not inevitable, they are encouraged in the present development climate.
Web Bundles is a fundamental solution to the problem bundlers start trying to solve. We need more browsers to get behind that.
After Web Bundlers are natively supported, bundlers can honestly focus on the build-pipeline problem area they naturally evolve into.
After Web Bundlers are natively supported, bundlers can honestly focus on the build-pipeline problem area they naturally evolve into.
Personally, I take the “run everywhere the same” aspect of web sites very seriously, so I don’t think bleeding edge browser features are an important part of the solution for me.
I also don’t think “build pipelines” are part of the solution.
But I do support you pursuing your vision of finality. Mine is pretty different, you can look up “browser bridge” on NPM if you are interested.
I also don’t think “build pipelines” are part of the solution.
But I do support you pursuing your vision of finality. Mine is pretty different, you can look up “browser bridge” on NPM if you are interested.
Every widely supported feature was once a bleeding-edge feature.
I'm not sure how you can about finding fundamental enduring solutions to platform gaps that user-space tools solve without adding platform features. That's always going to create a period where some browsers support a feature and some don't, and we've _always_ had to deal with that. It won't be different here.
I mention build pipelines because that's what most bundlers actually are. If they drop the bundling part, they can just focus on that.
I'm not sure how you can about finding fundamental enduring solutions to platform gaps that user-space tools solve without adding platform features. That's always going to create a period where some browsers support a feature and some don't, and we've _always_ had to deal with that. It won't be different here.
I mention build pipelines because that's what most bundlers actually are. If they drop the bundling part, they can just focus on that.
I think platforms “mature”, and nothing important happens after that. The web was mature around the time WebGL was widely adopted. Bundles don’t do anything we can’t already do. They just make the web more brittle.
Which means: lovely for you, until something snaps.
For me that’s two cons: lost users, and a more complex data model. And no pros.
Which means: lovely for you, until something snaps.
For me that’s two cons: lost users, and a more complex data model. And no pros.
That doesn't hold up with browserify => webpack though. Webpack came after Browserify, offered more features, but it was a pain to configure and had no sane defaults. It was still widely adopted and was preferred over the older, much easier to configure browserify, because of its flexibility.
Parcel's been around for well over a(two?) year(s) now and actually instigated a lot of change and refinement in the bundler market. Most now have zero-config options available, either as a result of Parcel coming on the scene, or with inspiration from it.
Thank you for bringing up how new Parcel is. It'll be interesting to see how we as an industry manage ten year old legacy projects built on top of nodejs/js.
You know, when there's a sudden request for a new feature in a project that's been ticking along for five years - and you need to install a development environment to add said feature - but the build system has been abandoned for three years...
You know, when there's a sudden request for a new feature in a project that's been ticking along for five years - and you need to install a development environment to add said feature - but the build system has been abandoned for three years...
Seems that Prettier.js has been able to hang on step 4 and almost avoid 5 and 6 (so far) :-)
I think that is precisely what makes it so desirable in any project, no more organizational fighting about insubstantial stylistic matters.
I would love that ClangFormat was the same. If you leave the door open to interpretations, interpretations will enter the room.
I think that is precisely what makes it so desirable in any project, no more organizational fighting about insubstantial stylistic matters.
I would love that ClangFormat was the same. If you leave the door open to interpretations, interpretations will enter the room.
This is generally true and I've seen it happening again and again. One of the exceptions (IMHO) that goes a bit the other way is Create React App. That's partially why I like it so much. It has become even simpler to use for the easy usecases. There's tutorials to do many of the complicated things, and you can always eject, but if you don't have convoluted needs it works very smoothly.
I met a software engineer once and said “what do you do on your team?”
He said “I’m the webpack developer”.
He said “I’m the webpack developer”.
How is this different from any build engineer? For some reason we generally accept that client development isn’t trivial except when it’s a web client, then it somehow must always be trivial despite it being the platform that must deal with things like application payload optimizations and work on every device. Meanwhile look how busy the rabbit hole of Xcode config on a complex app can keep an engineer for a single iOS app, and we seem to just accept it because it’s not web, and web = bad.
So, we make fun of a company that is serious enough about their web client to have a fulltime build engineer while we lament how little thought and care seems to be put into so many web clients in the wild. Maybe it turns out that clients aren’t always trivial and some specialization / division of labor is what it takes to make a good product.
It wasn’t long ago that you could see HNers snicker about fulltime “front-end developers”. I mean, isn’t it just HTML and CSS? How hard could it be? Isn’t the server API the only hard part of building a rich client??
So, we make fun of a company that is serious enough about their web client to have a fulltime build engineer while we lament how little thought and care seems to be put into so many web clients in the wild. Maybe it turns out that clients aren’t always trivial and some specialization / division of labor is what it takes to make a good product.
It wasn’t long ago that you could see HNers snicker about fulltime “front-end developers”. I mean, isn’t it just HTML and CSS? How hard could it be? Isn’t the server API the only hard part of building a rich client??
What does he spend his days doing? I wrote a configuration file years ago and I still use it for multiple projects. I only had to update it when upgrading between major versions of webpack.
This may not be a popular opinion, but if you need to dedicate a single FTE to your webpack configuration, something sounds amiss. Alternatively, if that's your engineers only skill (building webpack configs), that also sounds quite suspect.
In most projects, the webpack configs are not edited often, maybe unless you're upgrading a new major version of Webpack itself.
In most projects, the webpack configs are not edited often, maybe unless you're upgrading a new major version of Webpack itself.
They're not edited often because they're hard to edit. Many times webpack issues just get deferred or ignored because no one has the time to investigate them.
After testing it out on some personal projects, I switched a two year old core project at work from Webpack to Parcel. It took about 5 hours to get it right. The trickiest parts were finding the right alias mappings between TypeScript, our use of `~/` paths, and importing SASS files in TypeScript. This took about an hour. The next 4 hours were figuring out how to map the changes to eslint without Webpack.
It is much simpler to manage so far (though upgrading internal dependencies in general could be an issue over time). It compiles much faster as well. I'm not sure how the default bundle size compares to what we had with Webpack though.
It is much simpler to manage so far (though upgrading internal dependencies in general could be an issue over time). It compiles much faster as well. I'm not sure how the default bundle size compares to what we had with Webpack though.
I really dislike the huge, multi-faceted build systems calling themselves bundlers.
An ideal bundler would take a fully working unbundled project, which is easily writable with JS modules now, and just optimize it for production delivery.
The unbundled working app will be easier to develop and debug. Having a working project as input, and working project as output means that you can switch bundlers and aren't tightly coupled to it's transforms.
But most bundlers don't work this way (Rollup is the closest, and that's why I use it). Bundlers are typically entire build systems with compilers, CSS transforms, image optimization, etc... and they happen to bundle somewhere in the build pipeline. In the worst cases it's not possible to run the build but _not_ bundle, if you wanted to run some of the transforms.
This is all kinds of bad for the JS ecosystem. You can't really tell how a module will behave because the bundler is transforming everything. Imports aren't really imports, CSS is concatenated and magically added to the main document. Sometimes libraries publish code to npm that _only_ works with certain bundlers.
Web Bundles[1] is the way out of this. It's a standard bundle format that'll be natively understood by browsers, is unpacked before the network cache, and _only_ a bundling format. If you just want to bundle a working project, any Web Bundle tool will work.
[1]: https://web.dev/web-bundles/
An ideal bundler would take a fully working unbundled project, which is easily writable with JS modules now, and just optimize it for production delivery.
The unbundled working app will be easier to develop and debug. Having a working project as input, and working project as output means that you can switch bundlers and aren't tightly coupled to it's transforms.
But most bundlers don't work this way (Rollup is the closest, and that's why I use it). Bundlers are typically entire build systems with compilers, CSS transforms, image optimization, etc... and they happen to bundle somewhere in the build pipeline. In the worst cases it's not possible to run the build but _not_ bundle, if you wanted to run some of the transforms.
This is all kinds of bad for the JS ecosystem. You can't really tell how a module will behave because the bundler is transforming everything. Imports aren't really imports, CSS is concatenated and magically added to the main document. Sometimes libraries publish code to npm that _only_ works with certain bundlers.
Web Bundles[1] is the way out of this. It's a standard bundle format that'll be natively understood by browsers, is unpacked before the network cache, and _only_ a bundling format. If you just want to bundle a working project, any Web Bundle tool will work.
[1]: https://web.dev/web-bundles/
We’ve tried very hard to avoid Parcel specific features actually. When we transform, we use other tools that the user has enabled, eg babel. An application that you build with Parcel does not produce Parcel specific output and there are as of yet no Parcel specific language features. It should be possible to switch to another build tool without much if any work. Definitely not the case with other tools like webpack though, so I can see where this comes from.
Web Bundles are absolutely unrelated to Parcel and Webpack. The output of these two can just be wrapped in a Web Bundle or you can make it yourself.
It’s like saying a garage is the solution to your moving needs.
It’s like saying a garage is the solution to your moving needs.
its like when SDKs started calling themselves OSes, that was pretty confusing
Switch to Parcel from Webpack for my latest project. I was actually surprised that it just worked, I didn't even have to write a config file (being used to Webpack this felt like I saved hours of work).
I would like parcel much more if they just emitted ES Modules. I don’t understand the logic of having their own loader in 2020. Same complaint I have with webpack. Just target systemJS for older browsers like rollup does. Leveraging a very efficient existing well tested solution seems wiser to me than reinventing the wheel
I don’t understand why they don’t support that. You can really leverage smaller bundles this way (no bundler runtime for modern browsers for one). You can also leverage type=module in the browser (which parsers more efficiently by default[0]) and use the nomodule attribute for differential loading.
Of course this assumes browser targets, which I feel like is the main target for these tools most of the time.
[0] https://v8.dev/features/modules
I don’t understand why they don’t support that. You can really leverage smaller bundles this way (no bundler runtime for modern browsers for one). You can also leverage type=module in the browser (which parsers more efficiently by default[0]) and use the nomodule attribute for differential loading.
Of course this assumes browser targets, which I feel like is the main target for these tools most of the time.
[0] https://v8.dev/features/modules
One could also ask why you'd need parcel if you're already writing modern es module code. If you really need to bundle that (and you kind of don't, es modules allows you to put each requirement in your page html, and get the benefit of browser caching for individual pieces of the pie back, which you lost when you starting bundling and single-line changes to a single small class created entirely new hundreds-of-kbs bundles) use rollup.
If you know you're targeting modern browsers, the need for bundling is slowly disappearing again. And if you're targeting something like electron, there is _really_ no need to bundle because you're distributing the entire filesystem with load times that don't involve network requests.
If you know you're targeting modern browsers, the need for bundling is slowly disappearing again. And if you're targeting something like electron, there is _really_ no need to bundle because you're distributing the entire filesystem with load times that don't involve network requests.
If companies could, they would just send your browser a binary blob. From a business point of view, exposing your inner workings / modules is a no-go. Same for local apps using Electron, there's a (perceived at least) business need to obfuscate the code into a big ball of mud that is continuously changing with every build so external patches cannot be applied, e.g. Slack doesn't want you to have the ability to read or modify your local Electron client.
They will soon with WASM. I'm pretty sure this is the main reason behind it being pushed.
Efficiency with tree shaking is still very important, which is easier to manage with a bundler.
We have support for outputting native ES modules in Parcel 2, which is currently in alpha! We can even compile your app to multiple targets to support modern/legacy browsers. :)
2020...
I’ve used this with my most recent project 30 Hour Jobs. My goal was the quickest path to launch and this was hilariously easy compared to my old webpack config!
I can imagine at some point you might need more customizability with a tool like webpack - or maybe this will always be sufficient?
I can imagine at some point you might need more customizability with a tool like webpack - or maybe this will always be sufficient?
I had to switch on a project because I couldn't get IE support working :( A shame (that I have to support IE) because parcel is excellent.
I believe the new version will make it fairly easy to do differential builds - so users with modern browsers don't have to download all the Polyfilla but it still works on IE
I believe the new version will make it fairly easy to do differential builds - so users with modern browsers don't have to download all the Polyfilla but it still works on IE
I like parcel a lot, but one issue I've always had is that it watches your node_modules folder. The devs kind of pawned it off as a "feature not a bug"[1], but it results in tons of warnings etc related to watching too many files. I've since started using a symbolic link to the actual node_modules folder, but it's still just 1 extra hurdle that would be nice to not have.
[1]: https://github.com/parcel-bundler/parcel/issues/1557#issueco...
[1]: https://github.com/parcel-bundler/parcel/issues/1557#issueco...
After a while, they switched to watching directories instead of files, which seems to solve the issue you describe of too many watched files. https://github.com/parcel-bundler/parcel/pull/1665
We’ve actually rewritten our watcher for Parcel 2 as a cross platform C++ module and it should be much more efficient. :) http://github.com/parcel-bundler/watcher
Haha, Chokidar [0] strikes again! So much time could have been saved by so many devs on Linux if that package had saner defaults. More than one of my package.json .scripts objects have "sysctl fs.inotify.max_user_watches=32768" embedded somewhere...
[0] https://www.npmjs.com/package/chokidar
[0] https://www.npmjs.com/package/chokidar
Has anyone used Parcel as a replacement for create-react-app? I own some tools for generating React projects in an enterprise environment and CRA (specifically react-scripts) has been a huge thorn in my side. Most of these projects are small to medium size and so they don't really warrant custom Webpack configurations. I'd prefer something with react-script's simplicity but without it's absurd restrictions.
Yes. And the create react app documentation actually links to parcel as an alternative. I messed around with webpack, gulp, and others for weeks trying to find a good option that could handle my existing code alongside newer code that would be written in react and that could handle multiple entrypoints. I had a difficult time with most tools until I tried parcel, and it just worked.
Have an entrypoints for a react app? Include that in the build and parcel can bundle and deploy with no configuration. It just knows it's react because of the import react statement. Want to use typescript with react? Just use .ts files.
So my parcel command while developing is something like 'parcel watch src/*.ts. I just put my entrypoints there and my components below that. I've actually been able to just code for a while now without having to fuss with build tools.
Have an entrypoints for a react app? Include that in the build and parcel can bundle and deploy with no configuration. It just knows it's react because of the import react statement. Want to use typescript with react? Just use .ts files.
So my parcel command while developing is something like 'parcel watch src/*.ts. I just put my entrypoints there and my components below that. I've actually been able to just code for a while now without having to fuss with build tools.
Thanks for sharing. What about non-build features like testing and linting? I think that's the one thing I'd miss from react-scripts.
I think Parcel would be a great option for your use case, shameless plug I have a boilerplate repo you could fork to get started: https://github.com/jdmg94/minimum-parcel-lib
I use Parcel by default in such projects.
Out of the box, with the default configuration, it already supports JSX, including hot-module reloading. So yes, it could be a replacement.
Out of the box, with the default configuration, it already supports JSX, including hot-module reloading. So yes, it could be a replacement.
Parcel has support for React Fast Refresh!! https://github.com/parcel-bundler/parcel/pull/3654
We use Parcel in our Microfrontend Framework Piral (https://github.com/smapiot/piral), too. Overall, this was an awesome decision. In the past we used Webpack a lot, but it just does not feel right any more.
I've also written a small article comparing different options: https://blog.bitsrc.io/choosing-the-right-javascript-bundler...
I've also written a small article comparing different options: https://blog.bitsrc.io/choosing-the-right-javascript-bundler...
I’ve been moving my projects to using es modules natively (supported natively in node 13 and with `<script type="module">` in the browser) and it’s pretty nice. There is no compilation step needed between edit and run. And when its ready for production, rollup is plenty.
I feel like node getting native es modules was the last step that the platforms needed to get up to speed with the bundlers. And the state of HTML, CSS, and JavaScript is good enough to simply use it without any external helpers (until production that is).
I feel like node getting native es modules was the last step that the platforms needed to get up to speed with the bundlers. And the state of HTML, CSS, and JavaScript is good enough to simply use it without any external helpers (until production that is).
There was a period where I started seeing Webpack everywhere, being used by everyone, so I felt obliged to try it. I struggled with the concepts and configuration and eventually realized that I completely failed to figure them out. It was a heavy blow to my developer self confidence. Fortunately I recovered when I discovered Parcel shortly after. "No config" immediately caught me after the frustration. I'm grateful for and still use it.
I love how it even supports Elm out of the box. It's a great feeling to replace your complicated web-of-magic-incantations webpack-config.js with a simple build command that just calls `parcel`.
At the very least, it's nice to default to parcel on a project and then, if needed, adopt webpack once your project matures the point of needing more fiddling.
At the very least, it's nice to default to parcel on a project and then, if needed, adopt webpack once your project matures the point of needing more fiddling.
I was amazed when I could point parcel to a html file that imported a typescript file and it worked. Only downside was that I was importing the script as a module and then half of the typescript imports stopped working. Had to bundle everything as one big typescript file to work around it.
I think they fixed this in Parcel 2 but didn't try yet.
I think they fixed this in Parcel 2 but didn't try yet.
Parcel looks promising, especially to finally free yourself from Webpack's configuration soup, and the compilation time gain looks great. I just wish it has better TypeScript support, it looks like it's still not possible to check types on compile, which is kind of a deal-breaker for me.
also https://packem.github.io/
and another build tool that's perf optimized: https://github.com/swc-project/swc
and another build tool that's perf optimized: https://github.com/swc-project/swc
Packem is still only availably as a binary, and they seem very reluctant to release the source code.
(And swc is more similar to Babel than to Webpack/Parcel.)
(And swc is more similar to Babel than to Webpack/Parcel.)
> Packem is still only availably as a binary, and they seem very reluctant to release the source code.
https://github.com/packem/packem/issues/4
oh yikes, the fact that it's closed as "irrelevant" is rather worrisome. how is it irrelevant to ask where the source code is for a project hosted on an open source hosting platform.
one of their top talking points is "Its crust is built with Rust", but without source to verify this it might as well be written in brainfuck.
sorry for linking it :(
https://github.com/packem/packem/issues/4
oh yikes, the fact that it's closed as "irrelevant" is rather worrisome. how is it irrelevant to ask where the source code is for a project hosted on an open source hosting platform.
one of their top talking points is "Its crust is built with Rust", but without source to verify this it might as well be written in brainfuck.
sorry for linking it :(
To be fair, the "platform for open source" is itself, also not open source.
I gave this a try for one of my experiments, replacing rollup. Wow. It just works and cleans up a bunch of dependencies.
All I need now is some one shot solution for eslint + prettier. Right now that's 7 dependencies, representing almost all the dependencies I add to most of my mini projects.
All I need now is some one shot solution for eslint + prettier. Right now that's 7 dependencies, representing almost all the dependencies I add to most of my mini projects.
Parcel is broken on Windows. Since 2018. https://github.com/parcel-bundler/parcel/issues/1990
How far from zero config do I have to go if I want typescript and jsx? The result is a single bundle.js?
Seems TS is provided by default (tho it will not do any type-checking, you'll need tsc --noEmit for that).
As for JSX, you need a basic tsconfig that specifies jsx.
src: https://parceljs.org/typeScript.html
src: https://parceljs.org/typeScript.html
Parcel is one of my favorite open-source projects. Love to see it getting some attention here.
Is there a Parcel equivalent of create-react-app ?
i used to maintain create-react-app-parcel, but lost interest and handed it off. you might still look into it.
im less interested in replicating the contract of CRA now, and want other defaults, so i made https://github.com/sw-yx/rincewind
im less interested in replicating the contract of CRA now, and want other defaults, so i made https://github.com/sw-yx/rincewind
pretty cool. thanks!
is there something better than gulp for older projects that don't use imports? basically concatting scoped JS
great and easy alternatives to webpack, I'm surprised its website appears to be mentioned first time at HN.
Not the first time https://news.ycombinator.com/from?site=parceljs.org
Considering parcel is listed in the create react app documentation as an alternative to cra, I'm surprised it hasn't received more mentions.
How does this compare to webpack?
Parcel vs Rollup?
Just use Make.
Takes just as long to learn, and is transferrable everywhere.
Takes just as long to learn, and is transferrable everywhere.
These are not task runners. Make alone will give you about 2% of what you'll need to bundle a modern web app.
Make can run all the tools like babel, uglify, etc.
Are there any good examples of projects using Make for a web app?
Facetious answer: Are there any good examples of projects using Parcel for a web app? ;)
Real answer: probably, but a ton of production code is closed-source.
But why restrict to web apps? Most influential software projects in the world use Make.
Real answer: probably, but a ton of production code is closed-source.
But why restrict to web apps? Most influential software projects in the world use Make.
We should have a gentleman's agreement to stop saying "blazing" + "fast".
Doesn't that just mean how quiqly it can burn down your CI pipeline due to a bug introduced deep in the dependcy graph?
I think Webpack 5 is around the corner, which was suppose to speedup Webpack to blazing fast ( With Caching and Hashing if I remember correctly ) .
Not sure if it is up to the speed of Parcel though.
Not sure if it is up to the speed of Parcel though.
[deleted]
Agreed. Either we ditch the term, or reach a scientific agreement on how many "blazing fasts" there are to a "regular fast".
lucisferre(4)
Does anyone else cringe when they read "blazing fast" X? Seems like "blazing fast" is thrown around too easily these days.
[deleted]
I still don't understand why everybody is using Webpack when Browserify is easier, simpler, faster, produces smaller builds, can be understood by a normal person. Really, the big shift from Browserify to Webpack happened to fast and without any clear reason.
With that said, it's good that someone is challenging Webpack, as that must happen for the sanity of all.
With that said, it's good that someone is challenging Webpack, as that must happen for the sanity of all.
I think it's always nice to call out the contributions certain corps are making to the OSS world.