Open yvele opened 5 years ago
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 changelog.md
or history.md
or release notes if they exist.
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:
ncu --openChangeLog express
ncu -o express
@brettz9 Sure there already are homepage
, bugs
and repository
package.json properties. A changelog
one would make sense.
ncu
could also try to guess the changelog URL by checking each dependency for:
changelog
/changelog.md
history
/history.md
changes
/changes.md
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 guess-changelog
package π
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 license
in package.json
(and really if transitive dependencies change their licenses as well, since linked licenses count too). It is indeed helpful to know what one is getting into with any given upgrade... :)
(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 license
but it seems that https://github.com/npms-io/npms-api allows one to get license
meta-data (e.g., https://api.npms.io/v2/package/npm-check-updates ). If they were to implement https://github.com/npms-io/npms-api/issues/92 , we could search for changelog
as well. (And to get really carried away, using the groupings of https://github.com/delfrrr/npm-consider (they have a getLicenseType
module that can be used), one could report if changes in license were to more "restrictive" or "permissive" license types, giving users a basic idea about what those new licenses meant.))
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 think it could (at least partially) cover the needs described in this issue.
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 package.json
for repository.type === "git"
. If true, extract the URL to the repo. If not, then it'd just not display any link as it currently does. (I realize this is slightly more complicated than I described, but looking at the package.json repository spec we should be able to get a usable URL in most cases.)
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:
--format detail
. We already have the --ownerChanged
option and we may have other opt-in options that add additional detail in the future. Better to create an option that accommodates all of them rather then adding more and more individual options. The --format
option could specify combinations in the future for more control.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 package.json
which is likely already on disk. Any direct dependency will be in the top level directory of the project's node_modules
and there we can parse the package.json
with no additional network requests. Not only would this make it far faster but also not be limited by the GitHub API rate limit.
We can still add this option under --format detail
if that's the long-term plan, but I'd advocate for this being the default behavior when ncu
is run since there's little additional cost and there's a huge benefit to it "just working" out of the box.
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.
My proposal was to check the
package.json
which is likely already on disk. Any direct dependency will be in the top level directory of the project'snode_modules
and there we can parse thepackage.json
with no additional network requests. Not only would this make it far faster but also not be limited by the GitHub API rate limit.
Great idea, that will be much faster.
We can still add this option under
--format detail
if that's the long-term plan, but I'd advocate for this being the default behavior whenncu
is run since there's little additional cost and there's a huge benefit to it "just working" out of the box.
In order to maintain the minimalist design principle of npm-check-updates
I'd like it to be opt-in, but I agree it will be a very useful feature.
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.
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?
ncu --format group,repo
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:
Provides a link to the package's documentation so you can decide if you want the update.
Originally posted by @yvele in https://github.com/tjunnone/npm-check-updates/issues/555#issuecomment-508802010
Originally posted by @raineorshine in https://github.com/tjunnone/npm-check-updates/issues/555#issuecomment-508826303
Originally posted by @yvele in https://github.com/tjunnone/npm-check-updates/issues/555#issuecomment-508864031
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.