pnpm --recursive flag in non-monorepo causes unwanted 'link:' version
#22458
Replies: 4 comments 7 replies
-
|
Also reported an issue over in the pnpm GitHub repo: |
Beta Was this translation helpful? Give feedback.
-
Did you decide to ignore the instructions to create a Discussion first, or did you just click through without paying attention to the two warnings? |
Beta Was this translation helpful? Give feedback.
-
|
If users already ignore the existing warnings then I think we'll find them ignoring the text of any checkbox too, but we can try it. Ultimately 90% of bug reports turned out to be a mistake (this one is an example too, despite being well written) and the result was wasted maintainer time and polluted issues. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I've heard of similar situations from other open source teams. Eg. Vercel has set up a separate private issue tracker in Linear and leaves the GitHub issues for the users. They watch the issues from their users and link the relevant, real issues to their tracker. Some similarities to what Renovate is trying to achieve with GitHub issues and discussions, although involving an extra private platform, which may be extra setup / overhead that Renovate wants to avoid. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting info. I also prefer the transparency of public Discussions+Issues, including that users can comment/contribute to Feature Requests and Bug Reports once they've been created by a maintainer |
Beta Was this translation helpful? Give feedback.
-
Missing the current warnings
I can see how you can miss the first warning here:
But I'm surprised that you missed these warnings in the issue form:
Pit of failure and the proper fix
I agree this is a bad user experience for people new to our repository. To fix this properly we would need GitHub to:
Inattentional blindness
This sounds similar to the study where people were asked to count how many basketballs a group of people where passing. Many people focus so much on counting the throws, they completely miss the person in the ape suit walking through the group. 😜 Checkbox to the rescue???
I doubt adding a checkbox is a good roadblock. We already have:
I agree with @rarkins comment:
Adding a checkbox clutters up the form, and is another thing for the maintainer to do before getting to fill out the form proper. Anyway, here's a PR for the checkbox idea, so we can preview the forms on my branch: Edit: the closed PR above is replaced by this one: Other methods like Vercel
That sounds like a lot of work for us. I prefer keeping things on GitHub, so everything is in one place only. |
Beta Was this translation helpful? Give feedback.
-
|
I think that if users already click past our warnings today then a checkbox is unlikely to make a difference other than more work for maintainers, so let's not do that |
Beta Was this translation helpful? Give feedback.
-
|
Just to circle back around here and note that this usage by Renovate of the
Eg. this PR here: Diff of first commit by Renovate bot (the
First commit by Renovate bot broken, second commit fixed with my GitHub Actions workflow workaround:
|
Beta Was this translation helpful? Give feedback.
-
|
@karlhorky can you create a reproduction of this? i.e. a repo which has ideally one PR, where that PR is broken due to the problem you describe? |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible. Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues. To get started, please read our guide on creating a minimal reproduction. Good luck, The Renovate team |
Beta Was this translation helpful? Give feedback.
-
How are you running Renovate?
Mend Renovate hosted app on github.com
If you're self-hosting Renovate, tell us what version of Renovate you run.
No response
If you're self-hosting Renovate, select which platform you are using.
None
If you're self-hosting Renovate, tell us what version of the platform you run.
No response
Was this something which used to work for you, and then stopped?
I never saw this working
Wanted end result.
I originally reported this issue over at #22457 but auto-closed from the bot 😫
Given a repo package that:
pnpm...the
versionin the pnpm lockfile will be updated to'link:'.Example Renovate bot commit from update PR:
97d1a7c(#144)Relevant part of the diff:
This can be problematic for tools like ESLint, which may not be able to resolve the dependency (see failed test run):
As far as I have investigated, this occurs because of the
--recursiveflag forpnpm installthat Renovate uses, added in this PR by @ianwalter (reviewed by @viceice):In the PR, @ExE-Boss brought up the concern that running
pnpm install --recursivein non-monorepo may cause unwanted behavior - @zkochan replied that "This should be fine."Apparently, in most cases it probably is fine (since there have not been many users reporting problems), but in this particular circumstance, it causes an issue.
Suggested Solution
I'm not sure what I would suggest in this case - I guess not adding
--recursiveforpnpm installif it's not a monorepo, but maybe that would be a downside for some reason?Workaround (GitHub Actions workflow)
In this commit in the PR, I added the following step to my GitHub Actions workflow, to manually add back the package using
pnpm addand then commit the result to Git:It creates new commits from the GitHub Actions bot account (example commit):
What you tried so far.
Described above
Relevant debug logs
Logs
Beta Was this translation helpful? Give feedback.
All reactions