Suggestion: Make Yarn user friendlier (i.e. zero-config for most users which don't need zero-install)

[brillout]

I really like Yarn Berry's relentless focus on pushing the edge of what's feasible with a package manager.

But I wish it would be simpler to use when I don't need advanced features.

Is there a way to enable a simpler get started for users that don't need advanced features? Is there a fundemental reason to not have a get started like the following?

npm install -g ber # Yarn *Ber*ry
git clone [email protected]:brillout/vite-plugin-ssr
cd vite-plugin-ssr/
ber # Installs all deps
ber dev # runs script `dev`. We're done.

(Sorry about my previous post, I meant in a constructive way.)

[arcanis]

While better, this post still isn't actionable under this form - you do not say what's the problem you face. Compare with #3448 - I don't ask as much details, but you have to describe the specific issues you got, or there's nothing we can do to solve them.

[brillout]

Thanks for the answer😊 And in general thanks for everything you are doing, I truly appreciate it. (I should have written that in my previous post, sorry.)

My problem is that I want to minimize the amount of effort that goes into getting started with Yarn Berry.

For example, I tried multiple times to try out Yarn Berry but I always gave up because it took too much energy to get started.

Step-by-step:

1. npm install -g yarn: makes sense
2. yarn set version berry: hm, starts to become idiosyncratic but ok it makes sense as I can see why it's like that. (That said, I can't stop wondering if it wouldn't be easier to just create a new package ber and then simply ship beta releases on npm, instead of doing some custom versioning mechanism. But I don't know Yarn Berry's details and you probably have good reasons.)
3. Now I have .yarnrc and .yarn/ in my repo. I don't know whether I should check them in? And https://yarnpkg.com/getting-started/install doesn't say anything about this.
4. I have to dig into the docs to eventually find https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
5. The What files should be .gitignored section mentions "If you're using Zero-Installs" but 1. a first-time Yarn Berry user has no clue what "Zero-Install" is, 2. I don't want to decide yet, I'd rather have Yarn Berry give me a sensible default.
6. So now I'm digging into this zero-install thing (even though all I wanted was to try out Yarn Berry, now I'm spending time on something else).
7. I'm looking at https://yarnpkg.com/features/zero-installs and I see "It has some drawbacks", but what are these drawbacks? I (with all due respect) consider it rude to mention drawbacks without saying what these are. How am I suppose to make an educated decision then?
8. I decide against zero-install (since I don't know what these drawbacks are) so I add the following to my .gitingore:

   .pnp.*
   .yarn/*
   !.yarn/patches
   !.yarn/plugins
   !.yarn/releases
   !.yarn/sdks
   !.yarn/versions
   

   Here again, I can't stop wondering if this huge list is really necessary? I never had a tool asking me to add that many files to my .gitignore / to my repo. Isn't that leaking some internal concepts to the user? Again I don't know Yarn Berry and you probably have good reasons to do this, but this does raise one's eyebrow.
9. I'm reading .yarn/cache and .pnp.* may be safely ignored, but you'll need to run yarn install to regenerate them between each branch switch - which would be optional otherwise, cf Zero-Installs.. Ok that's annoying, not only do I have to type yarn install (and remember to do it which I'll probably forget many times before it becomes a reflex) on each git checkout but I also now have to tell all my contributors about this; I already see a bunch of contributors telling me "I can't contribute because your vite-plugin-ssr repository doesn't work". Thinking of it, that's actually already a blocker right there. I don't want this. Even if I decide that it's ok, I still need to take the decision which is annoying in itself and further distracts me from trying out Yarn Berry.
10. I'm further reading https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored and I'm now confrontend to bunch of internal concepts. I don't want to have to understand Yarn Berry's internals.

At that point I already give up. These many hiccups break my trust; if I loose already so much time to get started, how much more time will I lose using Yarn Berry on a daily basis?

I don't mean to be disrespectful in any mean, but this is a real problem that I believe should be addressed in a profound and fundamental way. On a high-level Yarn Berry seems very promising and it's saddening that it doesn't get the success it deserves because of lack of user friendliness.

Thanks again for pushing the envelope, I really do appreciate it 😊.

[saini-g]

Hi @brillout
I'd like to share my 2 cents on this topic. This is an important topic and I also faced some of the questions when starting out with yarn, so I think I can understand the frustration you are facing, but I can assure you that it does get easier from here.
I started experimenting with yarn 2 weeks ago and now I almost can't imagine going back to npm.

Regarding the Step-by-Step you mentioned above

Re: yarn set version berry: hm, starts to become idiosyncratic...

This is just one way of starting with yarn berry. By default yarn init uses yarn v1, which, I think we can all agree, is more inline with the npm flow.
You can also do yarn init --install-berry to start directly with yarn berry. I believe this will remove your confusion as to why a weird new command is needed when we're used to starting with npm init. The --install=berry is just a new addition to the old yarn init way, which I guess is pretty easy to catch up to.
NOTE: the full command that I'm currently using is yarn init --install=berry --workspace --private

Re: Now I have .yarnrc and .yarn/ in my repo. I don't know whether I should check them in?

I fully agree that making such decisions can be really confusing in the initial stages of learning new tooling, but I think the problem here is caused by the command yarn set version berry and not the tool itself. I recommend that you try out the yarn init --install=berry command once, and I'm sure you'll be surprised how many of your original confusions are already taken care of.
It generates the following .gitignore file

/.yarn/*
!/.yarn/patches
!/.yarn/plugins
!/.yarn/releases
!/.yarn/sdks

# Swap the comments on the following lines if you don't wish to use zero-installs
# Documentation here: https://yarnpkg.com/features/zero-installs
!/.yarn/cache
#/.pnp.*

This will remove you problems with reading about what files should be ignored or not, however you would still have to read about Zero-installs since that is a conceptually new thing with yarn berry.
But as a new learner to yarn myself, I just chose to swap the lines in the gitignore and didn't face any inconveniences at all during the whole learning process and when I was pretty comfortable with the basics, then I chose to go back and ready about what this new Zero-install thing was all about, and after reading just one small docs page I decided it's not for me.

Looks to me like almost all of your confusion is with the git related flow, and like you wrote "I'd rather have Yarn Berry give me a sensible default."
I think I can safely say that both of these points are addressed with the yarn init --install=berry command (Please correct me if I'm wrong on this)

Re: point number 9

This is where it gets interesting for me. Everything that I've learned until now would have served me very well in a private project or run of the mill projects at a day job, but if we're talking about open source projects things are not so simple.

Open source projects is one big area where yarn berry can be seen as a "not good" option because of the weird and new incompatibility issues (probably a poor choice of words) like the one you mentioned above - "I can't contribute because your vite-plugin-ssr repository doesn't work"
And I believe this was bound to happen, the whole node_modules philosophy has been going on for so long that if someone comes along and tries to get rid of it, then a lot of things are bound to break.

PS: I'm not advocating for one approach over the other and not saying that one is better than the other, just that both have their own pros and cons and are really well suited to different use cases. Also, I may have chosen my words poorly when I said "if someone comes along and tries to get rid of it, then a lot of things are bound to break." but I think that's the reality

I think for a long time I personally wouldn't give first preference yarn for an open source project but other than that yarn is very quickly becoming my go-to choice for new projects

I would very much like to further this discussion and hear more people's thoughts on this, especially from @arcanis about all the open source projects related stuff. Because that is one area where adoption will face the most friction as majority of the tooling is so tightly built around (quote-unquote) node_modules that even making slight changes can have big effects

I believe this was the reason for the birth of the editor SDKs to be included in the '.yarn' directory, and similar reasonings can be made for other files in that directory.

One last thing I'd like to say is that I too excited for what the future looks like and if given the choice I would personally prefer yarn berry over the traditional approach.

[brillout]

Zero-install seems quite like a drastic move. Why not skipping zero-install from the getting started step and just let user opt-in if they need zero-install down the line?

All-in-all it seems to me that user friendliness has been neglected a lot. For example, a succinct sumary of zero-install is an absolute must in the docs (that answers the question of "What is zero-install?" & "When should I use zero-install?" in the most succinct possible way and in a "explain-me-like-I-am-5" way).

About:

you'll need to run yarn install to regenerate them between each branch switch

That's a no-go from my perspective. Is that really necessary? Is there a way to get rid of this annoying step? I'd rather use a slower alternative like Yarn Classic than having this annoyance.

In the end, if I write all this is because I still believe in the project's capability in becoming mainstream. My criticism is meant to be constructive :-).

[arcanis]

Zero-install seems quite like a drastic move. Why not skipping zero-install from the getting started step and just let user opt-in if they need zero-install down the line?

Because the offline mirror (upon which zero-installs are based) already existed and was largely unknown (most of our users weren't aware of its existence, causing them to experience breakages each time the registry went down). I strongly believe that projects intended for production shouldn't rely on the network to install their projects, and one way to clearly convey that was to make it opt-out rather than opt-in.

That's a no-go from my perspective. Is that really necessary? Is there a way to get rid of this annoying step? I'd rather use a slower alternative like Yarn Classic than having this annoyance.

How is that related? Don't you have to run yarn install when switching branch on other package managers, to ensure the node_modules is in sync with whatever is the package.json in the new branch? That's part of what Zero-Installs are intended to solve, I don't see what you mean.

All-in-all it seems to me that user friendliness has been neglected a lot.

Yarn is perhaps slightly more intended for power users than it used to, at the moment, yes.

For example, a succinct sumary of zero-install is an absolute must in the docs (that answers the question of "What is zero-install?" & "When should I use zero-install?" in the most succinct possible way and in a "explain-me-like-I-am-5" way).

Quoting the documentation:

While not a feature in itself, the term "Zero Install" encompasses a lot of Yarn features tailored around one specific goal - to make your projects as stable and fast as possible by removing the main source of entropy from the equation: Yarn itself.

Feel free to suggest a better wording.

[saini-g]

Because the offline mirror (upon which zero-installs are based) already existed and was largely unknown (most of our users weren't aware of its existence, causing them to experience breakages each time the registry went down). I strongly believe that projects intended for production shouldn't rely on the network to install their projects, and one way to clearly convey that was to make it opt-out rather than opt-in.

Wow!, never thought of it this way. Thanks for the explanation

How is that related? Don't you have to run yarn install when switching branch on other package managers, to ensure the node_modules is in sync with whatever is the package.json in the new branch? That's part of what Zero-Installs are intended to solve, I don't see what you mean.

What I get from this and the docs is that a yarn install would only be needed when the dependency list in package.json changes and not for literally every branch switch

[arcanis]

What I get from this and the docs is that a yarn install would only be needed when the dependency list in package.json changes and not for literally every branch switch

Yes, which is also the case if you don't check-in the .pnp.cjs or cache.

[saini-g]

Why not skipping zero-install from the getting started step ...

I guess that zero installs is still an opt-in feature, or an "optional philosophy" as yarn's docs call it, but the fact that it depends on 1 line in the .gitignore file that is not commented out by default could be the cause of a less than ideal starting experience for people who are just trying out the tool. And this could be changed fairly easily if you ask me, just by reversing the default comments in the auto generated .gitignore file from yarn init --install=berry

you'll need to run yarn install to regenerate them between each branch switch

I couldn't agree more, this introduces unnecessary friction. But the more I think about it, the more I can't wrap my head around why this would be needed in the first place (again, my thought may be due to my lack of deep knowledge about yarn's internals).

This is how I imagine the flow would be

1. run git clone ...
2. run yarn install
3. now we can code as we would in a traditional npm or yarn classic project.

Any further yarn installs would be needed only when the dependencies of the projects have any changes.
Since the .pnp.* and .yarn/cache are part of .gitignore, these wouldn't be modified by a branch switch and if I switch to a new branch with a new dependency in package.json, then it would make total sense to run yarn install (which is true for npm and yarn classic too)

I think this is just a case of bad docs, not a bad tool.