sanity
sanity copied to clipboard
sanity-io
Leave package manager choice up to the user
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.
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?
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).
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.
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?
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? 😅
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!
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.
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.
This package would probably be very useful when moving over to npm: https://www.npmjs.com/package/libnpm
Any progress on this? I'm a new user of Sanity, trying to learn it, and I find the yarn mess incredibly annoying...
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 tuned!
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... 😕
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.
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"
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.
Just to add to this discussion, I just opened #2218 which I think is related to the discussion, as the bundled Yarn version used by sanity-cli seems to be causing issues with Yarn 2.
+1 on this just went through a bit of a hell trying to get yarn vs npm working on vercel for various reasons
I am trying to setup a new yarn 2 workspaces project, and unfortunately the studio doesn't work with it. I guess for now, I will use the classic version of yarn until this is resolved. It definitely would be nice if we could use whatever package manager we wanted. 😸
Hi! We don't have any updates on this for the moment. We totally get why it makes sense to have the CLI be package manager agnostic, but it's non-trivial to make it so with the current setup. It's on our list of things to look at when we revisit the CLI tool though.
Hi there.. just want to drop my use case which might be nice to take into consideration.
Problem
I currently have a monorepo with my CMS and Website (and other packages not relevant for that explanation) using pnpm:
.
├── apps
│ ├── cms
│ ├── cms-sanity
│ ├── lambdas
│ └── website
├── config
├── packages
│ ├── core
│ ├── mdx-prism-2
│ └── styles
└── scripts
└── common
When I created my sanity project, I had to cd to apps folder and run sanity init and because of the automatic dependency resolution, it installed dependencies with yarn.
Then, I had to delete yarn.lock and node_modules from my sanity project and run pnpm install.
After playing with sanity a bit, I wanted to add a plugin (markdown text block) and the same problem happened. It adds the content needed but also resolve the dependencies.
Despite taking too much time (because my project "had no yarn.lock or traditional node_modules"), it installed everything.
Once again, I had to delete yarn.lock, node_modules and install all dependencies with pnpm.
To end this up I faced this one more time adding cloudinary plugin.
Suggestion
I was wondering if we can either skip the dependency resolution process by default OR provide an option to skip this process. If I only had my code changed by codemon, I wouldn't mind to run install myself. Something like:
sanity install asset-source-cloudinary --no-install
Just to add a bit more motivation to this issue, I'm currently trying to get Sanity working within a Nrwl NX workspace with some degree of success, but the way that dependencies are managed for the studio is not consistent with how NX handles them. Normally NX has a root node_modules folder and a root package.json file to make it easier to keep all libraries and applications on the same version of common dependencies. It's not an absolute deal breaker, especially at an early stage of a new project, but I can see this becoming cumbersome for me later on when I have multiple studios with their own package JSONs and dependency versions.
The package.json part could be a separate issue that I'm happy to open if the maintainer's would like, but at least having the tool use NPM or to be package manager agnostic would be a huge step in the right direction for better compatibility with NX and other tools.
Edit:
An additional issue that I ran into is any packages that are directly referenced by files from within the studio (such as the schema files) need to be installed in 2 places. They need to be installed in the Studio's node_modules and in the root node_modules. NX commands will break if there are any unresolved dependencies referenced by those files and NX cannot resolve them unless they're in the root node_modules folder.
Anyone who uses NX, you can create package.json inside your app folder (eg: apps/react-app/package.json). This will create a separate node_modules from NX's root and you can pretty much serve its own dependencies.
I've been trying to use with pnpm workspaces in a monorepo at it seems real hit and miss. I had a strange bug with my reference types. Luckily I found this bug which was a very similar on the same blog sample in fact https://github.com/sanity-io/sanity/issues/709, when I read the the answer about NPM it clicked with me that it must be pnpm, low and behold I blew away the node_modules in my sanity app folder, ran an npm install and it fixed it. This looses the benefits of pnpm workspaces though :-(.
With Sanity v3, we now no longer ship with yarn, or do any package upgrades for you - instead it will try to find which package managers you have installed and prompt you for which one to use during installation. Thanks for your patience on this!
With Sanity v3, we now no longer ship with yarn, or do any package upgrades for you - instead it will try to find which package managers you have installed and prompt you for which one to use during installation. Thanks for your patience on this!
@rexxars Great news 🎉 Look forward to testing Sanity v3 with pnpm in a rush.js monorepo setup 🤞
