Renovate documentation - Link relevant bugs and issues to package managers’ documentation

[betterPeleg]

What would you like Renovate to be able to do?

In the documentation of the Renovate supported package managers, I would like to add all related current open issues, both bugs and feature requests.

This will provide 2 main benefits:

• Better visibility for users regarding known bugs and limitations within the relevant package manager’s use cases, along with feature suggestions currently in the pipeline.

• Better documentation to be automatically published in each released version of the Renovate tool.

If you have any ideas on how this should be implemented, please tell us here.

Go over GitHub’s issues list and filter them based on labels:

• Each supported package manager has its own designated label.

• Only issues that were scanned by a contributor and assigned a priority will be looked at (no issues of “priority-5-trige”).

Add an automatically updated segment in the documentation package manager web page that will list:

• Title of issue in GitHub (including issue number)

• Link to GitHub issue

• Indication wether the issue is a bug or a feature

Is this a feature you are interested in implementing yourself?

No

[betterPeleg]

open questions:

• Should there be a clear segmentation between bugs and features (different lists)?
• Should the bug/feature indication be literal or using some sort of graphics?
• Any more information to provide (other labels of the issue)?

implementation suggestions:

• how do you recommend implementing this using minimal manual maintenance

[HonkingGoose]

This issue is similar:

• https://github.com/renovatebot/renovatebot.github.io/issues/169

I think we should just give our readers a query string to a search on GitHub. ^quote

Example table

It sounds like you want something like this:

Table of open issues for manager:gradle:

Issue	Priority	Status
#15044	priority-4-low	status:ready

Pre-filled query strings

Creating and maintaining the code to fetch the list of open issues and to create the table in the docs sounds like a lot of work. 😄

How about we give the reader a link to a pre-filled query on GitHub, like this:

## List of open bugs for Maven package manager

Find [open and confirmed bugs for `manager:maven` on GitHub](https://github.com/renovatebot/renovate/issues?q=type%3Aissue+is%3Aopen+label%3Atype%3Abug+-label%3Apriority-5-triage+label%3Amanager%3Amaven).

To try this out yourself copy and paste type:issue is:open label:type:bug -label:priority-5-triage label:manager:maven into the GitHub issue screen on the renovatebot/renovate repository.

Here's how it works:

1. Only display issues, don't show PRs with type:issue
2. Only display open issues with is:open
3. Only show issues labeled as bug with label:type:bug
4. Exclude priority-5-triage label by putting a - sign before the label: query, like this: -label:priority-5-triage
5. Only display issues with the label manager:maven with label:manager:maven

References

• GitHub Docs, searching issues and pull requests
• GitHub docs, understanding the search syntax

[rarkins]

I think it's worth the effort in this case

[betterPeleg]

I think there is also value in presenting the feature requests, and not only bugs (as @HonkingGoose suggested). this will inform users of specific capabilities that we still do not support (but might be in the pipeline) and may also prevent duplication of GitHub issues.

I would suggest simple indicators for the bug/feature list:

Is there more important information you think should appear in the list?

[rarkins]

I think show both. Either group them into two separate lists or show the labels like you suggest if they're in a combined list

[betterPeleg]

my suggestion is separating them into two lists:

[rarkins]

Keep the heading shorter for each, and make sure to clarify that the lists were built at the time of release and may have changed since.

[RahulGautamSingh]

Hey @rarkins Can I work on this one?

[rarkins]

@betterPeleg do you know if anyone else started this yet but forgot to self assign it?

[betterPeleg]

yes, Gabriel is assigned to it already

[Gabriel-Ladzaretti]

Below is the autogenerated doc for npm: few questions:

1. I'm hitting a rate limiter (two queries per manager) as im using the GH api to get the issue list. will we have this issue when building the docs?

2. repo:renovatebot/renovate type:issue is:open label:type:${ty} -label:priority-5-triage label:manager:${manager} is the query im using, any refinements? we are also getting some really old ones

3. Currently im limiting the query result with per_page=30, is this enough/too much? (npm for context has 21 feat, 7 bugs)

4. When we get an empty query response, do we omit the list all together or should we print out "None" or similar ?

   title: Automated Dependency Updates for Npm sidebar_label: Npm

   Renovate supports updating Npm dependencies.

File Matching

By default, Renovate will check any files matching the following regular expression: (^|/)package.json$.

For details on how to extend a manager's fileMatch value, please follow this link.

Supported datasources

This manager supports extracting the following datasources: github-tags, npm.

Additional Information

The following depTypes are currently supported by the npm manager :

• dependencies
• devDependencies
• optionalDependencies
• peerDependencies
• engines : Renovate will update any node, npm and yarn version specified under engines.
• volta : Renovate will update any node, npm and yarn version specified under volta.
• packageManager

Known open bugs

• Renovate removing dependencies in "unaffected" package in monorepo #12891
• Renovate cannot upgrade npm to an incompatible version when engine-strict=true is in .npmrc #12068
• Renovate doesn't update yarn.lock anymore with --install.frozen-lockfile true in .yarnrc #11356
• Invalid Yarn v1 lock file maintenance result #10331
• Renovate removed a or clause when updating node engines in package.json #7469
• Private dependencies are not updated #7354
• yarn lockfile update fails with skipInstalls and high trust #6443

Open feature requests

• Support node_modules that live in source control #13926
• Handle more complex yarn resolutions #12605
• Support npmv7 (lock file v2) for transitiveRemediation #10371
• Detect if npm package file is nodejs-only #9616
• Upgrade yarn when version policy is on #7429
• chore commit type when only the lockfile is updated #6791
• Add NPM Audit data to add more detail to Renovate PRs or limit to merge requests to only vulnerability fixes #6027
• Improve story for creating PRs to update to nightly builds #5872
• Update github hashes in npm package.json files #5640
• Semver-compatible branch committish incorrectly getting rolled back to tagged versions #5170
• npm: Add support for node compatibility checks #4826
• latest is not supported as a valid version spec for dependencies in a package.json file #3945
• Feature request: Rushjs monorepo support #3681
• feat(pnpm): support package.yaml and package.json5 #3653
• Vulnerability remediation using Yarn resolutions #3093
• Update dependencies to resolve security vulnerabilities in sub-dependencies #3080
• Feature Request: Add tag after bumpVersion and automerge #2928
• bumping the version doesn't execute npm preversion hook #2463
• Group remaining @types PR's #1799
• Suppress @types versions that are greater than companion package version #1372
• Special handling for npm @types #519

[rarkins]

Below is the autogenerated doc for npm: few questions:

1. I'm hitting a rate limiter (two queries per manager) as im using the GH api to get the issue list. will we have this issue when building the docs?
2. repo:renovatebot/renovate type:issue is:open label:type:${ty} -label:priority-5-triage label:manager:${manager} is the query im using, any refinements? we are also getting some really old ones

You should remove the label:manager label:type filters and instead do this:

1. Fetch all non-triage issues once
2. For each manager, perform client-side filtering to extract its relevant features and issues using the same list you fetched once at the start

3. Currently im limiting the query result with per_page=30, is this enough/too much? (npm for context has 21 feat, 7 bugs)

It's still one API call whether you use the default 30 per page or the maximum 100. Use 100

4. When we get an empty query response, do we omit the list all together or should we print out "None" or similar ?

We can probably omit the heading/section altogether for managers with no results

[rarkins]

Use "Open bug reports" instead of "Known open bugs"

[viceice]

on CI we can use GitHub token to raise request limits

[betterPeleg]

1. maybe we should show only first 3 or so (of both bugs and features) and the rest will be collapsed. even though all open issues should appear.
2. we need to add - "Updated to the latest Renovate release date (version number)". Im just thinking wether in the title of both "Open bug reports" and "open feature requests" or as a note in the bottom

@rarkins

[HonkingGoose]

Collapsible admonition

1. maybe we should show only first 3 or so (of both bugs and features) and the rest will be collapsed. even though all open issues should appear.

How about using this Markdown to get a collapsible admonition in our docs:

<!-- prettier-ignore -->
??? note "Click me to see the list of open issues"

    - Support `node_modules` that live in source control [#13926](#)
    - Handle more complex yarn resolutions [#13926](#)
    - Support npmv7 (lock file v2) for transitiveRemediation [#13926](#)
    - Detect if npm package file is nodejs-only [#13926](#)

You can click on the arrow to expand/collapse the section.

Change mkdocs.yml config first

Before we use this in production we must first edit the mkdocs.yml file so it uses the pymdownx.details plugin that's bundled with Material for MkDocs. [^docs]

  # The Details extension supercharges the Admonition extension, making the resulting call-outs collapsible, allowing them to be opened and closed by the user.
  # We're using this to enable collapsible admonition blocks for the list of bug reports and feature requests per manager.
  - pymdownx.details

[^docs]: Material for MkDocs documentation, Details

[Gabriel-Ladzaretti]

Currently im limiting the query result with per_page=30, is this enough/too much? (npm for context has 21 feat, 7 bugs)

It's still one API call whether you use the default 30 per page or the maximum 100. Use 100

Actually i meant to ask if a list of 30 max is too much to have in the docs. As suggested, a collapsible list would be beneficial here

[HonkingGoose]

Actually i meant to ask if a list of 30 max is too much to have in the docs.

We should show a complete list if we can. It gets confusing if we show a partial list. We can hide the full list behind the toggle, so it's not showing all lists items for all managers at once. 😉

If we can't show the a complete list then we should say so:

• list item 99
• list item 100, end of first API call

Note: there are more items on the list, but we can't show them.

[Gabriel-Ladzaretti]

showing all is not a problem, we have 752 all in all before filtering so 8 api calls will do. A collapsible list would be a nice touch so the data wont be very noisy.

[viceice]

• renovatebot/renovatebot.github.io#179

• 15936

[renovate-release]

:tada: This issue has been resolved in version 32.79.0 :tada:

The release is available on:

• GitHub release
• 32.79.0

Your semantic-release bot :package::rocket:

[renovate-release]

:tada: This issue has been resolved in version 32.82.0 :tada:

The release is available on:

• GitHub release
• 32.82.0

Your semantic-release bot :package::rocket: