-
Notifications
You must be signed in to change notification settings - Fork 325
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
Feature: Show changelog URL for each new detected versions #570
Comments
After a brief search, there does not appear to be a library that finds/guesses the changelog location. keepachangelog.com is the closest thing to a standard. It would be a handy library. A simple version would likely just look for a Related: #76 |
This would be awesome, standard or not. You can put in your vote for this proposal so there is an official mechanism for it: https://npm.community/t/standardize-a-changes-log-property-for-pointing-to-changes-md-history-etc/6704/2 If implemented, please also check "CHANGES" (also mentioned in https://docs.npmjs.com/files/package.json?_ga=2.65360558.1070215979.1569202581-1621332275.1569202581#files ). Not sure it'd be seen as out of scope, but it'd also be great to have a utility like:
|
@brettz9 Sure there already are
It's kind of a makeshift job but that may save developer priceless time looking for each changelog URL.. 🤔 PS: That is maybe an idea for a dedicated OSS project, something like a |
Yes, I think a separate project actually makes the most sense, though your original idea to list them would no doubt be very helpful as well (and I'd think ncu could add that proposed separate project as a dependency in order to list them during the update process as you suggested). Not to crowd too many ideas into one feature request, but thinking about finding change logs (and also in the vein of knowing what one is upgrading) got me thinking of other projects which search various files for licenses, and I got to thinking that it would also be helpful to know before or during upgrades if a change in versions will correspond to a change in license, at least if reflected in a change of (For that, one might be able to use an existing project like https://github.com/jslicense/licensee.js or https://github.com/davglass/license-checker , though I know that in the case of at least the first, they are checking what is already installed, not querying license information (and I don't know that one can query npmjs.com to find out license info). It doesn't look like https://github.com/hughsk/npm-stats allows for |
Also of potential interest during updating could be changes in package file size (or for Deno projects, meta-data about permissions required). Anyways just seeding some ideas... |
I have written a small wrapper around ncu to get changelog urls: https://www.npmjs.com/package/get-changelog-cli |
I was going to submit this same suggestion so I'll add my 2c here. I understand there is no standard way to do this but a "best effort" approach would be a big improvement at the very least. Here's my proposal. In the package metadata there's a git link to the GitHub repository where the code is contained. That is present in almost every package and can be easily parsed to get the link to the GitHub repo. Even if we don't know how that specific repo manages change logs, simply linking to the repo would be a big step and only a click or two away from the information. So I'd say, check If you (@raineorshine) are on-board I'll try my hand at a PR. |
@CreativeTechGuy Luckily we don't have to do the fetching/parsing since @Clement134 has already done that in get-changelog-lib. It's just a matter of how to integrate it into ncu. Here's what I suggest:
i.e. $ ncu --format detail
Using config file /Users/raine/projects/npm-check-updates/.ncurc
Checking /Users/raine/projects/npm-check-updates/package.json
mocha ^7.0.0 → ^8.2.1 https://github.com/mochajs/mocha/blob/master/CHANGELOG.md
Run ncu -u to upgrade package.json If the above is satisfactory, I'm happy to provide guidance for a PR. |
No offense @Clement134 but I'm very hesitant to integrate a new, unused library into something this big. Although an even bigger issue is the limit to 60 requests per hour without an API key. For many projects that limit will be hit the very first time the command is run. I dug into your code and I see it handles more cases than my solution, but my solution also wouldn't require any additional HTTP requests. It seems like it's using the guess and check approach so that could mean 8+ HTTP requests per dependency. It's much cheaper to link to the repo's homepage and this can be done with 0 network requests. My proposal was to check the We can still add this option under In summary, I don't think this is a critical feature and so a least cost, best effort approach seems like the best way to go here. |
Great idea, that will be much faster.
In order to maintain the minimalist design principle of
Thanks for digging into the code. That seems reasonable. |
Okay sounds like a plan. I think I'll start with getting a basic POC that works and putting out a PR for you to review and then let me know how you'd like it to be refactored to fit with your organization vision and minimalist design. :) |
I was looking at adding this, but I think it already works?
EDIT, well I guess this links to the repo, not to a specific changelog |
@Sparticuz , yeah this is probably never going to be possible to add as originally described. The only solution would be to guess and check from a list of possible locations, but even that would miss all of the packages that have their own documentation site with the changelog. I think the current solution is likely the best that is possible, although it's not perfect output, it's the best we can do without making thousands of network requests trying to find changelogs on the internet. |
Even if we can't figure out the changelog for all packages:
Maybe we can start a movement for changelogs to be specified in package.json? btw, there is this ancient tool that works some of the time: https://github.com/dylang/changelog also, npm-check:
|
Originally posted by @yvele in #555 (comment)
Originally posted by @raineorshine in #555 (comment)
Originally posted by @yvele in #555 (comment)
Edit: For information,
npm
is showing the changelog URL like thisBut because
ncu
may show multiple times this kind of informations, we must find a way to fit the changelog URL in a one liner.Also, is there a standard way to get a package changelog URL? Sometimes it's the GitHub release notes page, sometimes a dedicated changelog page, etc.
The text was updated successfully, but these errors were encountered: