Closed (works as designed)
Project:
Drupal core
Version:
9.3.x-dev
Component:
javascript
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
2 Oct 2019 at 17:51 UTC
Updated:
2 Jul 2021 at 10:25 UTC
Jump to comment: Most recent
Comments
Comment #2
andypostComment #3
webchickIMO this would definitely be a Drupal 9 thing. We would not want to swap tooling this late in Drupal 8's cycle.
Comment #4
cilefen commented+1 It is simpler in the first place to require only NPM.
Comment #5
droplet commentedYou should not feel that's annoying because every developer has both on their computer. This need not tell non-Core contributors to use Yarn in the first place.
To me, Yarn still saving me 2 ~ 5sec on the hot cache (on different computers). If you making `yarn install` into your daily workflow on each git commit or git checkout, you will find the differences.
Yarn PnP - this is a thing and will be default with Yarn 2
Comment #6
spleshkaFrom the experience of my team, we went from "Oh, npm is the standard package manager in the frontend community, let's use it" to "Wow, npm doesn't have .lock file, we need to switch to yarn to keep the dependencies consistency. Also, yarn seems to be faster." and eventually landed with to "Actually, now npm has introduced .lock file and seems to be as fast as yarn (more or less). So let's revert back to the standard package instead of using third-party".
However, it's still not easy decision after all due to several reasons:
1. This
2. Yarn needs tiny bit less typing to run commands (i.e.
yarn buildinstead ofnpm run build) - Go lazy devs (me)!3. Yarn still seems to be faster in benchmarks. However, this difference isn't that significant as it used to be.
4. Yarn 2 has quite promising roadmap.
5. Yarn always aimed to include all features of npm + add some nice extras on top, so theoretically it should be more or at least as future proof as npm. However, npm was included into node package and de-facto became a standard, as well as got huge ecosystem around it, so I can barely imagine how yarn can beat npm in the long run.
To make the long story short, there's no crystal clear answer as to what package manager to use. For my team I've decided to stop switching between npm and yarn, get a large can of popcorn, take a backseat and wait until one of them wins the competition.
Comment #7
xjmThis would be indeed a 9.x thing, but it would be something that would need to be added with BC and deprecation as per our normal policy in some minor version of Drupal 9, so moving it to 8.8.x for now. That way it eventually will end up in the queue of the 9.1.x feature branch. :)
Comment #8
xjmComment #9
xjmAlso, the proposal would need review from the frontend framework manager to be considered. Thanks!
Comment #10
jibranWait, let's take a step back here. If we just drop the
yarn.lockfrom core and remove the yarn as an engine frompackage.jsonthen developers are free to use whatever they want.Also, we can add
.nvmrcand.yvmrcto help people use the correct versions.Comment #11
droplet commented#10
You can do it now freely. To use Yarn is designed for CORE contributors.
If Yarn is a problem, above 2 is 10x of Yarn for Linux & MacOS, 1000x for Windows users. PostCSS will be 100x for those who failed to install Yarn.
For the theme, the Claro, it can add a statement:
This is unlike CORE JS which is targeted to patcher, you can edit the CSS/JS files directly :p
Comment #16
nod_we're keeping yarn for now. On the JS packages side of things we're starting to use yarn2 pnp so we're getting more invested in that toolchain. I don't see a strong argument either against yarn or for npm, so closing.