You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi team - I'm probably going to be annoying with issues over the next few days as I explore but the very first thing I noticed is the inability to install via NPM in any way:
npm i
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: @vue/[email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/eslint
npm ERR! dev eslint@"npm:[email protected]" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer eslint@">=8.40.0" from @antfu/[email protected]
npm ERR! node_modules/@antfu/eslint-config
npm ERR! dev @antfu/eslint-config@"2.4.2" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! /***-eresolve-report.txt
npm ERR! A complete log of this run can be found in: /***-debug-0.log
While I respect the opinion to use ni (I had not heard of it), it's a bit of a barrier to teams who purposely choose to stick close to the "approved" ecosystem. In my case, I have to provide details of our CI/CD pipeline to people who might not love / may not yet have vetted pnpm, etc. So being unable to use the out-of-box npm candidate is a pain point. Worse yet, version locking in our ecosystem is provided by fnm so the cache benefits of pnpm actually end up being a bit of a security detriment.
We run relatively strict development environments and I can tell you from experience that the requirement for pnpm would restrict more enterprise-oriented development contributions to the project. In our case, our app containers don't even have pnpm so to contribute to the project, we would need to modify the base images themselves which is obviously a barrier.
Recommendation:
Stick to npm for official published variations OR
At least make sure npm itself works to install the repo
Currently, even attempting this command after the pnpm installation fails: npm i --package-lock-only
Keep in mind other developer environments and LTS - many companies refuse non-LTS development (especially when something like Node's NPM supports it so fully).
Workspaces - which seems to be the primary draw of pnpm here - are supported in the latest NPM (perhaps not as exhaustively).
I'm sure you guys will close this as a TODO (I probably would) but it does mean I'm not going to be able to contribute to a codebase I am very interested in helping along the way.
The text was updated successfully, but these errors were encountered:
Thanks for your interest in this project ❤️ ! We use pnpm to ensure a consistent experience among developers and first-level support for workspaces. You can quickly install pnpm(or yarn) through corepack, which has long been supported in node-lts.
The debate over using npm or pnpm has been ongoing for quite some time, but the advantages offered by pnpm will far outweigh its limitations.
Regardless, if you have any topics of interest, let's continue the discussion.
Hi team - I'm probably going to be annoying with issues over the next few days as I explore but the very first thing I noticed is the inability to install via NPM in any way:
While I respect the opinion to use ni (I had not heard of it), it's a bit of a barrier to teams who purposely choose to stick close to the "approved" ecosystem. In my case, I have to provide details of our CI/CD pipeline to people who might not love / may not yet have vetted
pnpm
, etc. So being unable to use the out-of-boxnpm
candidate is a pain point. Worse yet, version locking in our ecosystem is provided by fnm so the cache benefits ofpnpm
actually end up being a bit of a security detriment.We run relatively strict development environments and I can tell you from experience that the requirement for
pnpm
would restrict more enterprise-oriented development contributions to the project. In our case, our app containers don't even havepnpm
so to contribute to the project, we would need to modify the base images themselves which is obviously a barrier.Recommendation:
npm
for official published variations ORnpm
itself works to install the reponpm i --package-lock-only
Workspaces - which seems to be the primary draw of
pnpm
here - are supported in the latest NPM (perhaps not as exhaustively).I'm sure you guys will close this as a TODO (I probably would) but it does mean I'm not going to be able to contribute to a codebase I am very interested in helping along the way.
The text was updated successfully, but these errors were encountered: