Compatibility - NPM fails to install project

[claylevering]

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.

[alexzhang1030]

Thanks for your interest in this project :heart: ! 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.