parcel: 🙋 Automatically install missing dependencies, part 2

I get the temptation to make Parcel be completely automatic, but you have to be careful to weigh the risks.

Parcel will have a good run for a few years. Why will Parcel fail? Because the codebase becomes too bloated and hard to change, just like Webpack.

I created a fork of Parcel called Parsley, and it was incredibly simple because we have no configuration. We don’t depend on any environment variables or console settings that users would expect to maintain across the fork.

Automatically installing dependencies is one of those things that seems cool at first, but when you think about it, what’s being saved? The users are slightly less annoyed for a few seconds? Typing yarn add foo --dev is too hard?

Worse, when it causes problems, it will cause problems in a huge way. Users will run into strange mysterious errors that they’ll have to google to get answers for. “Why is parcel foo.html failing for this Vue project?” “Oh, yeah, vue-hot-reload-api fails to install due to some bug in yarn. Really annoying, just run yarn add vue-hot-reload-api --dev manually.”

Combine this with the fact that we’re spinning our wheels on problems that don’t really matter. We could be focusing on impactful work such as extending the plugin system so that people have access to the core APIs from plugins. They can’t right now. There’s no way to override the behavior of the methods in Bundler. But we’re focusing our thought and energy into automatically installing dependencies instead, when no one really wants that aside from a few enthusiasts. And those users are important, but they’re not the cream of our crop: disgruntled Webpack users.

The bigger our codebase becomes, the harder it will be to deal with concerns that sprout up regarding all of these features. These features have to be maintained, and they have to work, and we have to respond to issues and PRs related to them. Codebase grows as O(n^2) with the number of lines, because lines tend to communicate exponentially with other parts of the codebase. It’s not strictly O(n^2), but it certainly isn’t O(n).

The cost of adding code outweighs the slight convenience of doing this.

That said, it’s a team decision. 😃 If everyone on the team wants this, then shrug go for it. But it’ll be the #1 thing users will want to turn off.

(If Parcel doesn’t add a CLI flag to turn it off, I’d stop using Parcel. But that just means I now have to remember to run parcel --no-install --no-cache index.html for development all the time now, which is quickly becoming hilarious.)

On Thu, Dec 21, 2017 at 11:14 PM, Devon Govett notifications@github.com wrote:

Now that #306 https://github.com/parcel-bundler/parcel/pull/306 has landed, it would be awesome to take this even further. Currently we automatically install dependencies loaded by the internal localRequire helper. These are things like compilers (e.g. typescript, coffeescript), and plugins (e.g. postcss plugins, parcel plugins, etc.).

It would be super cool to take this even further and transparently install any npm dependencies you require in your code for you. e.g. if you add require(‘react’) in your code, and it’s not installed, Parcel can install it for you.

Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/parcel-bundler/parcel/issues/376, or mute the thread https://github.com/notifications/unsubscribe-auth/AADo8HEj0pmj6l0W9wUtnyqET15ybYD7ks5tCzqpgaJpZM4RKpxg .

Because I don’t want parcel doing magical things for me. I want to know exactly which deps are added to my project and whether they’re installed as dev deps or real deps. And the only way to ensure that is to have control: to tell parcel “please stop trying to hold my hand.”

On Fri, Dec 22, 2017 at 3:18 AM, Jasper De Moor notifications@github.com wrote:

Why would there be a cli option to turn it off? If you install the dependencies up front then it wouldn’t even care to look to install them? You can just still use it the same way @shawwn https://github.com/shawwn And about the errors it’s pretty straightforward it says it fails to autoinstall so than u just run the command in very restricted business environments or wathever, we could even extend this warning to literally give them the command.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/parcel-bundler/parcel/issues/376#issuecomment-353556881, or mute the thread https://github.com/notifications/unsubscribe-auth/AADo8MoQWIxsgFX7mm6v-PyNnbP24no4ks5tC3PQgaJpZM4RKpxg .

For future reference: flag to disable this behavior is --no-autoinstall

(It’s similar to the reason I run with --no-cache: The cache isn’t perfect, and there are many cases where it fails. Those cases cost more time than the small convenience afforded.)

On Fri, Dec 22, 2017 at 3:31 AM, Shawn Presser notifications@github.com wrote:

Because I don’t want parcel doing magical things for me. I want to know exactly which deps are added to my project and whether they’re installed as dev deps or real deps. And the only way to ensure that is to have control: to tell parcel “please stop trying to hold my hand.”

On Fri, Dec 22, 2017 at 3:18 AM, Jasper De Moor notifications@github.com wrote:

Why would there be a cli option to turn it off? If you install the dependencies up front then it wouldn’t even care to look to install them? You can just still use it the same way @shawwn < https://github.com/shawwn> And about the errors it’s pretty straightforward it says it fails to autoinstall so than u just run the command in very restricted business environments or wathever, we could even extend this warning to literally give them the command.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/parcel-bundler/parcel/issues/376# issuecomment-353556881>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADo8MoQWIxsgFX7mm6v- PyNnbP24no4ks5tC3PQgaJpZM4RKpxg> .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/parcel-bundler/parcel/issues/376#issuecomment-353559341, or mute the thread https://github.com/notifications/unsubscribe-auth/AADo8Pi5rXmhZavMpSQ34ZiDmCjyecD0ks5tC3b6gaJpZM4RKpxg .

That came out a bit more rant-y than I wanted, but the gist is that if someone wants to set up react, it takes them ten seconds to install the dependencies.

If someone wants to use react without Parcel, it takes them ten minutes to configure Webpack.

That’s why Parcel is valuable. Saving ten seconds at the cost of maintainability and extensibility seems like a bad tradeoff, but maybe users feel differently. I don’t know.

@dpikt fyi this is documented in the docs: https://parceljs.org/cli.html#disable-autoinstall

@shawwn is raising some very good points here IMO. I agree that this whole auto-installation thing may be nice at first sight but extends the scope of this project into fields that should be left to actual package managers. Users should be kept in control of their dependency management, especially in work environments. At the same time, the freed-up resources could be spent on key features of a better bundler.

@brandon93s That’s exactly how it works now for compilers. e.g. import a .ts file and typescript is automatically installed and saved into devDependencies.

With all due respect, sir, you should try to suppress the impulse of making decisions for the users. You can give them the options and if they need it, they can just turn it on.

Parcel is all about developer experience. Anything we can do, no matter how small, to save developers time is a win in my book. Developer hours add up quick!

We’ll be working on things like improving plugins etc. in good time. Feel free to discuss how we can improve other aspects of Parcel in separate issues. There is room for everyone here.