Alternatives to Yarn

[erbridge]

Is there a particular reason for forcing use of Yarn? There are more package managers for JavaScript, such as pnpm or npm itself, and it would be useful to be able to use one of them instead. Each tool has its own cost-benefits. I'd settle for making it pluggable, and letting the community manage plugins for it.

[jakeNiemiec]

(comments here were made before Microsoft acquired npm)

Is there a particular reason for forcing use of Yarn?

The alternative is npm and they haven't been particularly ethical lately with the union-busting. Plus it doesn't have a good track record as far as bugs go (try googling : npm ERR! cb() never called! ).

Each tool has its own cost-benefits.

What don't you like about Yarn, what you do like about npm?

I'd settle for making it pluggable

It doesn't seem like it would be too hard, Yarn isn't too ingrained into webpacker (non-doc, *.rb files):

[jcoglan]

A question that would be worth considering is: why is package installation in scope for this library? If Node modules were being installed into Rails projects exclusively to support running Webpacker, then it would make sense to hide the implementation details, but that's not the case. node_modules has many other uses and developers need to directly interact with it beyond its role in supporting Webpacker.

What if we considered what it would look like for Webpacker to reduce the set of assumptions it makes about the Node environment to what's actually built into Node, i.e. the module resolution system built on package.json and node_modules.

It would be reasonable then, for example, for Rails to add entries to package.json for the dependencies it requires, and to run their executables via the node_modules/.bin directory. The installation of Node packages would then be up to the user, and Rails would not constrain how they install their front-end dependencies and run scripts.

[erbridge]

As I think @jcoglan aludes to, I think the question isn't about "why shouldn't we use Yarn?", it's about "why should we force a decision about how people must manage their dependencies on them?".

[jakeNiemiec]

why should we force a decision about how people must manage their dependencies on them

The installation of Node packages would then be up to the user, and Rails would not constrain how they install their front-end dependencies and run scripts.

I have certainly been where you are right now (#1938 (comment)) & understand where you are coming from:

@joelmoss I've now got to the point where I simply want to create my own Webpack config from scratch, without any external forces making further (unwanted) changes.

I talked about this in a long, recent mailing list post:

This is why vanilla webpack got so popular. It knows how to be the vehicle without making decisions for you. WebpackER turns what is supposed to be the equivalent of a "Makefile" into yet another "zero-config" framework.
There's the rub, during some crossroads/problem, users will realize that they can cut out the middleman and just write the exact webpack config that they want (it's already generated for them). They don't need to coerce webpackER to output the right config or translate Vue.js README instructions to webpackER compatible instructions.

If you like the idea behind this, go promote the eject PR. If a user has a problem that webpacker wont fix, like #1845, the user will at least have a path to solve it for themselves.

But, Rails is all about convention over configuration, you might just be outgrowing webpacker 👍. If the only reason for this ticket is to lobby for npm, I don't think that's going to happen (even with a PR).

[jakeNiemiec]

TIL, this was settled 3 years ago: #475 (comment)

[erbridge]

I guess my context is coming from working primarily in JavaScript land, where I've been accustomed to being able to make my own decisions about package managers. As I said in my original post, there are more package managers than Yarn and npm. I accept that Webpacker probably wants to specify some defaults, but unlike anything else I've come across in Rails, there's no way to override the default package manager for Webpacker. I'd be happy to work on a PR to make that possible without changing the defaults, but would that be considered for merging, or is this project completely set on Yarn being hardcoded into it?

[jakeNiemiec]

I have to respect what DHH said in #475 (comment), I cannot guarantee that a PR would be considered.

Webpacker is designed to work primarily with Rails 5.1+ and Rails has picked Yarn for now as the JavaScript packaging approach. That doesn't mean that someone couldn't go another route, but just that what we'll support out the box is Yarn. Now that we've extracted all logic from the tasks and moved them into the Webpacker class, it's trivially easy for someone who'd like to use a different approach to call the logic without relying on the tasks and prechecks we have.

Reading this again, I think a PR to document the path to pnpm/npm can be considered. Apart from that, feel free tag me if you run into any issues. 👍

Side note

The bower issue ( bower/bower/issues/2467 ) for moving to `npm` is the same issue number as this one, small world I guess.

[erbridge]

Ok, I'll take a look at this when I have some time. Thanks.

[arye-eidelman]

I recently had some issues with yarn. And followed this itnext.io guide to switch over to npm. It replaces the relevant yarn commands with their npm equivalents.
I think (hope) I've fixed the root issue I was having and switched back to yarn without testing this out much.

[jakeNiemiec]

@erbridge, in order to consolidate issues, let's continue in: #1746