Hacker News Reader

Comment by frankpf | Hacker News Reader

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

View on HN

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.

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)

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.

Yep, we’re definitely going this direction with Parcel 2. :)

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?

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?

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.

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.

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.

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

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.

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.

This one is even better (scifi, but possible to execute by humans).

https://www.teamten.com/lawrence/writings/coding-machines/

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.

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

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.

Reply on news.ycombinator.com