Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

get changelog from npm #9061

Closed
Tracked by #14138
k-yle opened this issue Mar 10, 2021 · 7 comments
Closed
Tracked by #14138

get changelog from npm #9061

k-yle opened this issue Mar 10, 2021 · 7 comments

Comments

@k-yle
Copy link
Contributor

k-yle commented Mar 10, 2021

What would you like Renovate to be able to do?

To be able to fetch the changelog from the npm package itself, if renovate can't find it on GitHub or GitLab.

If npm sees a CHANGELOG file, it will always publish it. This makes it potentially a more reliable than searching through the repo for tags, releases or changelog-like files.

This had advantages over the current approach because:

  • It works even if renovate can't find the source repo
  • It works even if renovate can't guess the release/tag version
  • It works if the git release versions don't match the npm versions
  • It works for packages in monorepos (see Improve changelog detection for monorepos #2926), even if they don't specify repository.directory in package.json (like @aws-amplify/auth)
  • It works for public packages that live in private repos
  • It works packages that don't live on GitHub or GitLab

typedoc-plugin-markdown and @aws-amplify/auth are some examples where the current approach fails, but fetching from NPM would work.

Did you already have any implementation ideas?

If getting the changelog from GitHub or GitLab fails, use

https://unpkg.com/{{package}}@{{version}}/CHANGELOG.md
@k-yle k-yle added priority-5-triage status:requirements Full requirements are not yet known, so implementation should not be started type:feature Feature (new functionality) labels Mar 10, 2021
@rarkins
Copy link
Collaborator

rarkins commented Mar 10, 2021

I think this has enough positives that it's worth doing. Some downsides to note:

  1. Releases are immutable, so the CHANGELOG entry for a release will never be added (if missing) or updated (if incorrect or incomplete) after publication
  2. We are relying on yet-another-external-service in the form of unpkg
  3. It's npm-only, naturally

In my experience CHANGELOG entries often are updated post-release.

Given these points, I wouldn't replace any of our existing logic with this, but instead supplement it just specifically for the npm case. I think we could use it as a fallback for fetching the changelog file if we can't fetch it through our usual means (e.g. it's on a supported platform, and we are able to locate the file).

What do you think?

@rarkins rarkins added priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others datasource:npm and removed priority-5-triage labels Mar 10, 2021
@k-yle
Copy link
Contributor Author

k-yle commented Mar 10, 2021

Sounds great @rarkins!

As you said, I think it would be valuable to have npm as a fallback source if the better options (GitHub/GitLab) fail.

  1. Releases are immutable, so the CHANGELOG entry for a release will never be added (if missing) or updated (if incorrect or incomplete) after publication

That's definitely a drawback, but if this is the last resort then I think showing something is better than nothing. And if the package has a CI process to generate a changelog alongside the release then this won't be an issue.

@rarkins rarkins added status:ready and removed status:requirements Full requirements are not yet known, so implementation should not be started labels Mar 10, 2021
@rarkins
Copy link
Collaborator

rarkins commented Mar 10, 2021

Yes, I agree. There are still a few unknowns to explore here - for example we usually try to avoid datasource-specific logic in lib/workers/* files - but I think this is acceptable to move ahead to development with, if you or someone else is willing.

@marcodejongh
Copy link
Contributor

This will also fix changelog generation for packages in public npm, published from a private repo.
I wish there was an alternative to unpkg though, as we also have private npm packages (in our own registry) that we'd like changelog generation for. But just fixing the public usecase would be a huge win.

I'd be willing to help out. Are you suggesting @rarkins that we just add fetch changelog last attempt in the global changelog fetching logic? Which I think is in: lib/workers/pr/changelog/index.ts ?

@viceice
Copy link
Member

viceice commented Mar 25, 2021

Yes, i think here

something like:

if (!res) {
  res = await sourceUnpkg.getChangeLogJSON({ ...args, releases });
}

@rarkins rarkins added core:changelogs Related to changelogs/release notes fetching auto:reproduction A minimal reproduction is necessary to proceed status:requirements Full requirements are not yet known, so implementation should not be started datasource:npm and removed datasource:npm status:ready labels Jan 14, 2022
@github-actions
Copy link
Contributor

Hi there,

Help us by making a minimal reproduction repository.

Before we can start work on your issue we first need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction to understand what is needed.

We may close the issue if you (or someone else) have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

@rarkins
Copy link
Collaborator

rarkins commented May 14, 2023

A reproduction is still needed which demonstrates an update where the changelog is not found by Renovate today but is available via npm/unpkg

@rarkins rarkins removed type:feature Feature (new functionality) priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others auto:reproduction A minimal reproduction is necessary to proceed status:requirements Full requirements are not yet known, so implementation should not be started datasource:npm core:changelogs Related to changelogs/release notes fetching labels Oct 1, 2023
@renovatebot renovatebot locked and limited conversation to collaborators Oct 1, 2023
@rarkins rarkins converted this issue into discussion #24778 Oct 1, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants