-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-enable deprecated dependency warnings #5098
Comments
|
Relevant quote from @rarkins 1
And found another relevant quote from @rarkins 2:
Footnotes |
I'm labeling this Options to get deprecated dependency warnings going again:
@rarkins Do you want me to work on mockups for the Dependency Dashboard and the PR warning idea? |
I think we should default to using a single logger.warn if a repository has any deprecated dependencies. We should display the list of deprecated packages in the dependency dashboard (maybe grouped by datasource) if it is disabled. We shouldn't use a separate issue for this like we used to. Users should be able to ignore such packages individually - I think this is possible using ignoreDeps or packageRules today. Users should be able to turn off the warning altogether, using |
I'd love to see the ability to see upcoming deprecations as well where there isn't a replacement or new version found. For example with the endoflife-date datasource renovate might discover that a dependency is going EOL and we could notify the users. A replacement rule might need to be defined to resolve the EOL situation. Maybe a configuration that would allow a back off duration from the EOL date for the notifications to begin in the dependency dashboard? |
Good article on the state of deprecated NPM packages this morning. Another good reason to bump the priority on this. https://blog.aquasec.com/deceptive-deprecation-the-truth-about-npm-deprecated-packages |
Let's start with this being in the Dependency Dashboard. Option 1: Add a section towards the top of the dashboard warning if deprecated dependencies were found and listing them, perhaps grouped by manager. Option 2: Warning with a count of deprecated dependencies, then include a deprecated flag/badge next to the actual dependencies in the existing dependency tree I think Option 1 is easier. Delete the |
It would be nice for a later enhancement to indicate if any of these have replacement PRs available. |
I vote option 1I like option 1 best. A ordered list is more accessible and easier to understand than the counts, flags and badges of option 2. I think deprecated stuff deserves a bit of a "shout out". So putting it in a new section at the top seems best. When you open the Dashboard you will probably look at the top first. Putting it at the top also keeps it "above the fold" on small viewports/devices. Use alert syntax on GitHub?It might be nice to use GitHub's alert syntax, as that looks extra different. 😄 GitHub Docs, Basic writing and formatting syntax, Alerts If Mock-up of option 1, GitHub alert syntax, top of pageWarning Renovate found the following deprecated dependencies:
You should review the listed dependencies, and either request a update from Renovate via this dashboard, or upgrade manually. This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more. Markdown source for mock-up> [!WARNING]
> Renovate found the following deprecated dependencies:
>
> - Deprecated-stuff-1
> - Deprecated-stuff-2
>
> You should review the listed dependencies, and either request a update from Renovate via this dashboard, or upgrade manually.
This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more. Let me know what you thinkAs usual, tell me what you like and don't like about my idea. 😉 |
Group by manager or datasource? Or make the list flat, and include the datasource as part of the line, e.g.
|
To group or not to group
Each Git hosting platform has different limits on the amount of characters, some have low limits. We should probably avoid grouping, to save characters for the rest of the dashboard features. Plain list- thePackageName (npm) [replacement available]
- thePackageName (maven) Grouped list### npm manager packages
- thePackageName [replacement available]
### maven manager packages
- thePackageName I prefer the flat list
This looks best to me, for now. It's simpler than grouping things and costs less characters. Open PR from deprecation list? Looks bad...I was thinking of letting users open the replacement PR from the list of deprecated items. But this looks bad/broken when you mix replacement available, and missing replacement items:
- [ ] thePackageName (npm)
- thePackageName (maven) [no replacement found] I think this means that the actual replacement PRs go in their own Replacement PR section with proper checkboxes. As that way it will look/behave as expected. 😞 |
Usage of |
See: |
🎉 This issue has been resolved in version 37.410.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
I have a question about this: Is the dependency dashboard currently the only way to show deprecated dependencies and unsuppressing |
@dword-design please start a new discussion, we can discuss there |
What would you like Renovate to be able to do?
I would like Renovate to be able to raise issues for deprecated dependencies. Once a dependency has been removed or updated to use a non-deprecated version, Renovate should close the raised issue.
Describe the solution you'd like
I haven't seen any documentation on how to remove values from merged configuration arrays, but something like
suppressNotifications: ['!deprecationWarningIssues']
orsuppressNotifications: {'deprecationWarningIssues': false}
would be convenient ways of overriding merged configurations.Describe alternatives you've considered
There was previously an option called
raiseDeprecationWarnings
, which has since been deprecated and refactored into settingsuppressNotifications: ['deprecationWarningIssues']
instead. There is currently no way to preventdeprecationWarningIssues
from being added to thesuppressNotifications
array since it's always set during configuration migration.Additional context
Related issue/discussion: #2909 (comment)
The text was updated successfully, but these errors were encountered: