Skip to content

Compatibility - NPM fails to install project #142

@claylevering

Description

@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/devtools-monorepo@7.0.4
npm ERR! Found: eslint@8.55.0-1
npm ERR! node_modules/eslint
npm ERR!   dev eslint@"npm:eslint-ts-patch@8.55.0-1" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer eslint@">=8.40.0" from @antfu/eslint-config@2.4.2
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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions