Sanity: Consider only supporting npm

[bjoerge]

Supporting two different package managers with their own quirks and subtle differences is time consuming and error prone. Personally, because I'm more used to typing npm over yarn, I regularily run into issues caused by mixed use. I've seen that other users of sanity run into these kinds of issues too.

I also got bitten by the subtle differences in how npm and yarn hoist packages yesterday when attempting to fix #709. The initial fix worked when using npm, but not yarn, and in order to verify that the fix worked I had to test with both npm install and yarn install. This took several hours to figure out.

npm has improved greatly since yarn was introduced, and overall I think the issues that yarn solved when is now mostly fixed by npm.

Also, due to the dominance npm has in the Node.js ecosystem, I don't think its feasible for us to stop supporting npm.

Another point is the number of technologies you need to know about when maintaining a Sanity Studio project. Today we assume you use npm for installing the cli initially, but then stick to using yarn later on (e.g. when adding new dependencies to a studio). This is also not very clearly communicated from our docs (but that's another issue I guess).

I know that we have built a major part of the cli on yarn, and I assume it will take a considerable effort to replace yarn with npm, but I suspect only supporting one package manager will pay off in the long run, both for us and our users.

[rexxars]

I'm curious as to what you mean by _support_ in this case. Since we can't _block_ yarn from being used (unless we fail on the presence of a yarn.lock or similar), wouldn't the same issues occur to users anyway? Is saying "You need to use npm" good enough?

[bjoerge]

I was about to clarify that, actually :) I'm not proposing explicitly _not_ supporting yarn (et. al), but rather to change our official stance from today's _we use yarn internally, if you use npm you are on your own_ to instead be _we use npm internally, if you use yarn you are on your own_

Another option would of course be to support both officially, e.g. by making sanity upgrade conditionally use yarn or npm based on config (or presence of yarn.lock vs package-lock.json).

[rexxars]

I personally feel we should stick with one of them, and I'm open to switching to npm since it is after all the default package manager. Actually making use of both internally seems like something that would lead to a much larger surface area to maintain.

[rexxars]

As a side note; maybe we should warn on startup in the case where both a yarn.lock and a package-lock.json file is found in a studio?

[bjoerge]

Actually making use of both internally seems like something that would lead to a much larger surface area to maintain.

Agreed. Sounds like something that would introduce even more problems. For example: what do do if there are both package-lock.json and a yarn.lock? Pick the package manager to use based on which file was edited last? 😅

[bjoerge]

As a side note; maybe we should warn on startup in the case where both a yarn.lock and a package-lock.json file is found in a studio?

Thats a v good idea!

[rdunk]

To echo @bjoerge's first comment: As a new user I found it slightly confusing that the docs suggest using npm to install the CLI and JS Client, but then that yarn should be used to install dependencies when extending the studio.

As an npm user I'm not opposed to using yarn if it's required for the studio, but it might be helpful if it's explicitly stated somewhere in the docs... although admittedly yarn.lock is a giveaway.

[kmelve]

I support officially supporting npm.

In light of this, I also wonder how we could improve the dev-experience, considering we also have things like sanity install plugin-name and npm install package-you-want-for-some-preview-manipulation. I have many times confused the two.

[bjoerge]

This package would probably be very useful when moving over to npm: https://www.npmjs.com/package/libnpm

[kmelve]

FWIW: The Nuxt CLI lets you choose between npm/yarn.

[Svish]

Any progress on this? I'm a new user of Sanity, trying to learn it, and I find the yarn mess incredibly annoying...

[kmelve]

We haven't prioritized it since there hasn't really been much signal on this particular issue. That being said, we are now taking a look at it again to see if it's easy to swap out. Stay tunes!

[Svish]

Anywhere I can "subscribe to progress"? For something called Sanity, this issue is kind of making me lose mine while trying to learn this stuff... 😕

[kmelve]

I'm sorry to hear that. You can follow this issue at least.

[microbit-matt-hillsdon]

One practical motivation to support npm well for studio builds is that, so far as I can tell, if you put private packages in GitHub's package registry you can't use a mix of public NPM and private GitHub packages with yarn as the client. Given recent news from GitHub/NPM, it's likely more folk will try out this combination.

[jackblackCH]

I came here because of a related issue/thought: I wanted to figure out the difference of why a "sanity install any-plugin" is needed over an "npm install any-plugin"

[kmelve]

There's an explanation here @jackblackCH, let us know if it's still unclear 🙌.

[ricokahler]

Reading the previous comments makes me think this is mostly an internal discussion but if you don't mind me asking I'm genuinely curious on the team's stance now given npm 7 and yarn 2.