package should not use `yarn` as transitive dep

[aks-]

I am using npm but @oclif/plugin-plugins always pulls in yarn, looks like it's a transitive dependency

apollo → @oclif/plugin-plugins → yarn

It should not require yarn

This is where it's coming from -

plugin-plugins/src/plugins.ts

Line 12 in 716569c

import Yarn from './yarn'

I think it should not use yarn internally unless the user themselves is

[n1ngu]

Very much related to #71

[mcmxcdev]

Just came across this, can we get a move on? It's pulling in yarn v1 which is frozen and really old at this point.

[gonzaloriestra]

@mshanemc @WillieRuemmele could you please have a look at this? Yarn is a quite heavy dependency (~5MB), so it would be nice to get rid of it. Happy to help if needed!

[mdonnalley]

I'm closing this issue for a couple of reasons:

1. yarn is not a transitive dependency. It's explicitly listed in the package.json: https://github.com/oclif/plugin-plugins/blob/3.9.3/package.json#L19. The transitive nature you might have noticed is that yarn binaries by default resolve to whatever version you have globally. So while a yarn 1.x binary is being called, it could be resolving to a global 3.x binary. feat!: migrate to ESM #683 will change this to ignore yarn's resolution behavior.

2. We have no intention of dropping yarn since it allows us to manage the user installed plugins. Yes, we could rely on a globally installed version of yarn or npm - but that's untenable in my opinion since it incorrectly assumes that all users will have one of those package managers globally available to them. That being said, it is on our roadmap to switch to yarn 3

[ljharb]

It would be a correct assumption that all users have npm available to them, since it's included in node by default, and anyone disabling it intentionally would presumably be aware of the problems that would cause.

[mdonnalley]

@ljharb Yes npm would likely be available although there are users of the Salesforce CLI that work in extremely restrictive environments, so I don't believe it's a guarantee as much as you think it might be. But, regardless, our intention is to stick with a locally installed yarn for two reasons:

1. The difficulty and risk of migrating users between two separate package managers. It's not impossible but it's risky and not something we're entertaining at the moment.
2. Depending on the user's global npm or yarn means that their plugins state would be hosed anytime they switched from npm to yarn or between major versions of either of those. We would have to implement a solution to migrate between each of those (again, risky) or ask users to reinstall every single plugin again. Making such an ask typically wouldn't be unreasonable but it's not an acceptable ask for CLIs that are used commercially with customers that expect zero breakages or interruptions.

So our plan is to stick with yarn 1 and eventually to migrate to yarn (3 or 4).