Parcel uses yarn by default

[danielo515]

🐛 bug report

Continuing with #1923 (comment) I want to report that in absence of package-lock or yarn-lock parcel uses yarn by default.

yarn add v1.9.4
info No lockfile found.
[1/4] Resolving packages...

As you can see, yarn reports that no lockfile is found so, why is it using yarn ?
This is specially problematic when you use private packages and you have the credentials configured on .npmrc

🤔 Expected Behavior

By default parcel should use npm which is the more or less standard

🔦 Context

This is only a problem on CI environment

🌍 Your Environment

Software	Version(s)
Parcel	1.9.7
Node	8.11
npm/Yarn	6
Operating System	linux

[Hoishin]

Following up, this part of code determines which package manager to use:
https://github.com/parcel-bundler/parcel/blob/c9c5805866aa23d2a4e1809516d04c4296c0c17c/src/utils/installPackage.js#L74:L88

1. If no yarn command, use npm
2. If package-lock.json exists, use npm
3. Otherwise, use yarn

So situation like having yarn command and not having any lock files will result in using yarn.

It probably should be

1. If yarn command exists and yarn.lock exists, use yarn
2. Otherwise, use npm

[DeMoorJasper]

Originally the logic was:

There is a yarn.lock => try yarn, fallback to npm
No yarn.lock => use npm

This got changed recently (with the addition of auto-installed modules, to also use yarn if it's installed), it should probably be changed back.

Flagged it as bug (as it's not really a feature either), although it's not really a bug.

[danielo515]

May not be a bug, but definitely causes bugs if you are not using yarn, which may surprise many but is not the primary choice for everyone.

[zor-el]

How was this ever accepted as a bug?

The only two situations where yarn-vs-npm selection made a difference was (a) in new projects, and (b) for users who switched off lock files.

Regarding having a lockfile vs not, having one is best practice. Since there are only two options, not having one can be said to be worst practice (and it did cause a lot of havoc, which is why yarn came to being in the first place). NPM has since added support for lock files, but yarn is still the superior alternative.

In case of new projects, parcel's old selection logic ensured use of best practice and a superior technology for users who had it installed. Now we've ended up defaulting to inferior technology for new projects (even for yarn users), in order to accommodate worst practices of users who are stuck in a pre-yarn, pre-lockfile aera?

😞

[danielo515]

In case of new projects, parcel's old selection logic ensured use of best practice and a superior technology for users who had it installed. Now we've ended up defaulting to inferior technology

Those are just your opinions, and we all have one.
You have to take into account situations where people have to live with what they have, and they have no choice.
Not everyone likes yarn (yes, some people dislike your loved yarn package manager).
The problem I see here is, as usual, taking too much for granted and not even providing a way to the user to decide what they want to use.

[AxelTerizaki]

I, for example, is running into an issue precisely because yarn is used instead of npm

• I'm using node 12.
• react-scripts has dependencies which don't use fsevents < 1.2.9. 1.2.9 is the only 1.x version which works with node 12. It is an optional dependency that is only installed on macOS. So it fails to install on macOS with node 12 if fsevents < 1.2.9
• To work around this I had to put a resolutions block in my package.json and add "react-scripts/**/fsevents": "1.2.9" to force fsevents to use 1.2.9.
• yarn is suddenly turning fsevents into a mandatory dependency if it's present in the resolutions block. npm keeps it optional.
• Obviously, since it's now mandatory, fsevents is incompatible with win32/linux and errors out.
• I thus wanted to use npm with parcel, turns out I cannot.

[alex-dixon]

Maybe this could be configurable? Parcel is autoinstalling dependencies with yarn I don't think I need -- older versions of babel plugins, etc., even though I have the newer equivalents specified in package.json. I have a package-lock.json in the folder I'm running parcel from. It's a monorepo so there's other things going on. I tried --no-autoinstall and PARCEL_AUTOINSTALL=false but still trying to install things with yarn.

[zor-el]

A late but still very valid response:

Those are just your opinions, and we all have one.
[...] Not everyone likes yarn (yes, some people dislike your loved yarn package manager).

There is no need to get into emotional arguments (as indicated by the use of words like "loved", "like", "dislike"). It's not about opinions, but about facts, careful consideration of tradeoffs, and not being discriminating towards groups of people who make different choices than npm.

Lets's call these two groups npm'ers and yarn'ers. Now some facts:

1. npm is not a choice. It comes bundled with Node. Whether or not it is installed is not a differentiating factor between npm'ers and yarn'ers. The presence of yarn is, since its installation is a conscious choice.
2. Parcel used to apply precisely this differentiator to select a package manager, avoiding discrimination against people in the yarn group.
3. Now there is a group bias against yarn'ers, and it's irritating that the perfectly undiscriminating original policy has been overthrown by vociferous pseudo-arguments about what's a "de-facto standard" among package managers.

It's not about package managers. It's about people.

I would love for Parcel to (re-)establish a state of affairs where no group is discriminated against.

How about the following suggestion?

In the absence of a lock file, Parcel should default to the package manager that was used to install it.

So if Parcel was installed via npm, npm would be used. If it was installed via yarn, yarn would be used.

That way, both groups would have zero extra effort to kick off Parcel projects as long as they use their favorite package manager to install Parcel.

[DeMoorJasper]

This never was really considered a bug, as it is not

I did flag it as one as it had to get a label and the original logic for autoinstall changed, meaning we kinda did a breaking change since the previous behaviour ergo a bug maybe?

The PR changing this back to npm got merged and than reverted as Devon eventually said this was intentional and that we do want yarn to be the default if people have it installed, as having yarn installed is a choice.

On CI you should always have a lockfile so unexpected behaviour is kind of a result of not following best practices in the first place. To be honest having parcel use yarn if you don't have a lockfile is probably not the worste thing you can experience when not using lockfiles, there is a reason yarn introduced them...

I doubt we will ever revert this back to defaulting to npm if yarn is installed as there isn't any good reasons to do so.

We will however keep improving other aspects of auto-install and probably add a way to fully disable it in parcel 2.

Hopefully this resolves some final questions about why it's the way it is.

[zor-el]

@DeMoorJasper, thanks a lot for your quick response.

Personally I'm all for lock files and yarn, and your elaboration sounds like yarn would be Parcel's preference as well, but even with the newest Parcel release, parcel build w/o a yarn lock uses npm.

So I'm confused. It seems like you are saying Parcel defaults to yarn (which I'm fine with), but that's not what I'm experiencing. (The only way for me to get Parcel to use yarn on a fresh folder with sources only is a yarn init -y; yarn before the first parcel invocation.)

Am I supposed to install from HEAD?

[DeMoorJasper]

@zor-el thought we reverted the PR, apparently the revert never got merged in so we do default to npm unfortunately.

Maybe we can default to yarn again in Parcel 2, for now you can just have a yarn.lock file? As I said changing now would be a breaking change so we can't really do it anymore due to semver... So therefore the earliest we can change this is Parcel 2

[zor-el]

@DeMoorJasper, I see. Thanks for clarifying. It seems we are on the same page, and only semver is the obstacle. :)

To prevent more discussions that a preferrence of one package manager over the other might provoke, I suggested earlier a way that would be equally inclusive to both yarn and npm users: Default to the package manager that was used to install Parcel.

Do you think that's a realistic option? Does it make sense to issue a feature request or RFC for it?

[DeMoorJasper]

@zor-el sure, feel free to open a new issue for parcel 2 about that, I'm not sure how realistic it is. I guess it's possible.

[plinnegan]

I have the case where there is a package-lock.json in my project and no yarn.lock, but parcel still uses yarn because I have it installed, meaning my project now has used two package managers. I can see why there is debate around which one to use when no lock file is given, but surely when one lock file is present and the other is not is should install based on the type of lock file present which is specific to the project?