[Bug]: Can't install package from git repo using pnpm

[cimchd]

Self-service

• I'd be willing to implement a fix

Describe the bug

I created a fork on github and wanted to use it instead of the original npm package. On running yarn install with yarn2 the following error message occurs:

➤ YN0013: │ vite-ssg@https://github.com/cimchd/vite-ssg.git#commit=ed70ed342c7430f660447c0e3b82a41eec18ad1e can't be found in the cache and will be fetched from GitHub
➤ YN0013: │ vite-ssg@https://github.com/cimchd/vite-ssg.git#commit=ed70ed342c7430f660447c0e3b82a41eec18ad1e can't be found in the cache and will be fetched from the remote repositor
➤ YN0001: │ Error: vite-ssg@https://github.com/cimchd/vite-ssg.git#commit=ed70ed342c7430f660447c0e3b82a41eec18ad1e: Assertion failed: Unsupported workflow
    at /myProject/.yarn/releases/yarn-2.4.2.cjs:2:430959
    at async a.mktempPromise (/myProject/.yarn/releases/yarn-2.4.2.cjs:2:520558)
    at async /myProject/.yarn/releases/yarn-2.4.2.cjs:2:429255
    at async a.mktempPromise (/myProject/.yarn/releases/yarn-2.4.2.cjs:2:520558)
    at async /myProject/.yarn/releases/yarn-2.4.2.cjs:2:428681

To check if I did something wrong I created a minimal empty folder and did the following with yarn1:

$ mkdir testproject1 && cd testproject1
$ yarn init
$ yarn add vite-ssg@cimchd/vite-ssg

The result was a successfull install of the package.

I did some further investigations and found out, that when I tried the same with yarn2 and added a yarn.lock to the repo and it worked. For my purpose this is ok, but I think this is not the intended behaviour or the error message is not specific enough.

To reproduce

Repo without yarn.lock (Doesn't work):

$ mkdir testproject2 && cd testproject2
$ yarn set version berry
$ yarn init
$ yarn add vite-ssg@cimchd/vite-ssg#commit=ed70ed342c7430f660447c0e3b82a41eec18ad1e

or as one-liner:

$ mkdir testproject2 && cd testproject2 && yarn set version berry && yarn init && yarn add vite-ssg@cimchd/vite-ssg#commit=ed70ed342c7430f660447c0e3b82a41eec18ad1e

Same repo, but with a yarn.lock included (works):

$ mkdir testproject2 && cd testproject2
$ yarn set version berry
$ yarn init
$ yarn add vite-ssg@cimchd/vite-ssg#commit=16bf2083c778e6096299c11cf27234788572ee2b

or as one-liner:

$ mkdir testproject2 && cd testproject2 && yarn set version berry && yarn init && yarn add vite-ssg@cimchd/vite-ssg#commit=16bf2083c778e6096299c11cf27234788572ee2b

Environment

System:
OS: Linux 4.19 Ubuntu 20.04 LTS (Focal Fossa)
CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Binaries:
Node: 14.17.0 - /tmp/xfs-ccaeeffc/node
Yarn: 2.4.2 - /tmp/xfs-ccaeeffc/yarn
npm: 6.14.13 - /usr/local/bin/npm

Additional context

I tried the same with a lodash fork. It worked well although lodash has also no yarn.lock file (but a npm package-lock.json).
The vite-ssg package seems to be created with pnpm. Maybe this is the reason why it behaves different.

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[merceyz]

We haven't added support for pnpm yet

[seivan]

Any updates on this?
What's the work around, could I clone it locally, and refer to it?

[laptou]

@seivan

What's the work around, could I clone it locally, and refer to it?

Did you figure out if there is a workaround? I saw in #3618 that this is scheduled to be fixed in the next canary release, but I'd like to be able to keep moving forward in the meantime.

[flying-sheep]

Did that canary release happen already or is the PR still on track.

If this isn’t merged very soon: Can we implement a workaround and fall back to yarn instead of crashing with a failed assertion? Just seeing “Assertion failed: Unsupported workflow“ without any context is really bad UX.

[Philzen]

Is there any workaround for this? Quite a bump otherwise...

[RamDurgaSai]

Still getting the error

➤ YN0000: · Yarn 4.5.0
➤ YN0000: ┌ Project validation
➤ YN0057: │ example-project: 'nohoist' is deprecated, please use 'installConfig.hoistingLimits' instead
➤ YN0000: └ Completed
➤ YN0000: ┌ Resolution step
➤ YN0001: │ Error: @nanostores/react@https://github.com/ai/react.git#commit=a240052fd6da7d85a20ee9c872aca48205ef555e: Assertion failed: Unsupported workflow
    at /Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:189:1608
    at async Tn.mktempPromise (/Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:9:45514)
    at async /Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:186:56
    at async Tn.mktempPromise (/Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:9:45514)
    at async /Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:181:3066
➤ YN0000: └ Completed in 17s 377ms
➤ YN0000: · Failed with errors in 17s 384ms

Any updated on this issue ? may be

[arunbluez]

Still getting the error

➤ YN0000: · Yarn 4.5.0
➤ YN0000: ┌ Project validation
➤ YN0057: │ example-project: 'nohoist' is deprecated, please use 'installConfig.hoistingLimits' instead
➤ YN0000: └ Completed
➤ YN0000: ┌ Resolution step
➤ YN0001: │ Error: @nanostores/react@https://github.com/ai/react.git#commit=a240052fd6da7d85a20ee9c872aca48205ef555e: Assertion failed: Unsupported workflow
at /Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:189:1608
at async Tn.mktempPromise (/Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:9:45514)
at async /Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:186:56
at async Tn.mktempPromise (/Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:9:45514)
at async /Users/johndoe/Documents/GitHub/example-project/.yarn/releases/yarn-4.5.0.cjs:181:3066
➤ YN0000: └ Completed in 17s 377ms
➤ YN0000: · Failed with errors in 17s 384ms
Any updated on this issue ? may be

One of my colleagues was getting this error and i was not, so upon investigation, i had the 1.22 version which doesnt seem to throw any errors, this error shows up only after migrating to yarn/berry. Maybe this helps someone. Have a good day 🙏

[Daniel15]

@Philzen I (and many of the other people you mentioned) don't work on Yarn any more. Given the fact that there's only 8 thumbs up on the issue, it doesn't seem like a very widespread problem. PR #3618 was never published (it's still in draft status) which is likely why it was never reviewed. If a PR is submitted to fix this issue, I'm sure the team would be willing to review it. Just for my info - what is the use case for combining pnpm and Yarn?

…

On January 8, 2025 7:52:20 PM PST, Philzen ***@***.***> wrote:  Ouch. @addyosmani @arcanis @bestander @bgotink @BYK @clemyan @Daniel15 @deini @Embraser01 @eps1lon @Gudahtt @Haroenv @imsnif @justinfagnani @kaylie-alexa @larixer @merceyz @paul-soporan @paulirish @RDIL @samccone @torifat @wycats @wyze @zertosh @yarnbot before this kind of commit activim goes viral – could the yarn team maybe give an outlook regarding the plan for this (imho rather profound) feature? -- Reply to this email directly or view it on GitHub: #3169 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[vlascik]

@Daniel15 I can confirm it's still an issue and a one that will force us to abandon yarn if not fixed as well - if we need to use a github fork of a library that uses pnpm internally (and now we do), yarn install breaks.

Everyone in this situation, and it will only happen more and more often as libraries use pnpm more, will be forced to do the same - a package manager that can't complete an install is pretty useless.

[Philzen]

Just for my info - what is the use case for combining pnpm and Yarn?

@Daniel15 the use case is referencing repositories directly in package.json dependencies.

For example, this works:

"@livekit/react-core": "Philzen/livekit-react.git#commit=49aee1d6a6d3ad10cf19756de8d14817b46a490c&workspace=@livekit/react-core",

as that repo is yarn-based.
But this one fails with the dreaded Unsupported workflow error:

"@chakra-ui/react": "chakra-ui/chakra-ui#workspace=@chakra-ui/react",

This is actually a very common use case, i.e. when there are urgently needed fixes or features already available in the repository that i want to use in my project, but the maintainers haven't shipped them to NPM yet.

There are workarounds though:

1. fork the project and try converting them to yarn
2. build the fork, commit the dist folder and linking directly into the dist-folder

However, it would be awesome if those extra steps wouldn't be necessary for non-yarn repositories.

[justinfagnani]

@Philzen You really didn't need to spam a bunch of random people here.

[arcanis]

I'm going to lock this issue considering the notification issue. There's a PR opened, and it's still in draft mode, so it doesn't get merged. If someone wants to help the project they're welcome to rebase #3618 and bring it to finish line.