Changelog

[dantman]

View formatted RFC

[sindresorhus]

I think the changelog field should use https://github.com/<user>/<repo>/releases automatically if not defined and the repository field is pointing to a GitHub repo. This would mean it would automatically just work for most packages without any changes. Inference is used for many other fields already, like the homepage and bugs fields being inferred from the repository field.

[zkat]

I'm gonna point out there's also an alternative proposal over at #8 that takes a different approach than this. Neither of these is ratified, and feel free to discuss how y'all see these two interacting/intersecting.

My first impression of this specific proposal so far was that even though I really want a feature like this, I felt like we would be able to do so much more for this experience (even if this proposal is still part of the story we end up with). There's also some willingness on the npm website team side to support this sort of thing, which should let folks have a smoother experience in some cases, and we definitely know we could do some nice things related to this because changelog files already get included in tarballs. npm is definitely in the sort of position where we can set new standards, after all, rather than build features only for limited-but-existing standards 💚

Thanks for posting this! I look forward to the discussion developing and seeing what we all end up with. I'm excited!

[dantman]

I think the changelog field should use https://github.com///releases automatically if not defined and the repository field is pointing to a GitHub repo.

In my experience updating packages, only a very small number of libraries use the releases page for their changelog. Most of the time it's quicker to find the changelog from the readme instead of the releases page.

[dantman]

I'm gonna point out there's also an alternative proposal over at #8 that takes a different approach than this. Neither of these is ratified, and feel free to discuss how y'all see these two interacting/intersecting.

Auto-detection via files in npm registry instead of via VCS repository didn't occur to me before, so I thought of auto-detection as much harder. If everyone is fine with auto-detection. How about implementing the auto-detection described in #8 and also adding a changelog field.

We can use this pattern:

• If a changelog field is present, open it
• If a CHANGELOG, HISTORY, CHANGES file was detected in the registry, open the package page to to the changelog section
• Likewise handle GitHub releases automatically somehow (up to you whether the package page should try to read this info, or we should just open the GitHub releases page if it appears that the package documents releases in it)
• Otherwise open the homepage

This will give us automatic handling for the vast majority of packages. When it fails we'll send the user to the package's homepage where it is most likely that they can find their way to wherever a changelog is located. And any package with a custom changelog can use the changelog field to provide an explicit URL to wherever they host their changelog.

CC: @jefflembeck

Edit: I would also accept the GitHub commits page when auto-detection fails and the package uses a GitHub repo, still falling back to the homepage when that is not the case

[g0t4]

• Auto detection will encourage standardization which makes it easier to find without tooling.
• Are there any efforts to standardize a parseable changelog format? I imagine a future where npm outdated could show a list of changes per dependency (filterable too: breaking or major changes, new features, bug fixes)

[iarna]

We are ratifying the very similar #8, which covers the cli command and existing practices around the bundling of changelogs. The biggest difference is that it declines to add a new package.json field.