search

raineorshine / npm-check-updates

Find newer versions of package dependencies than what your package.json allows
Other
9.33k stars 323 forks source link

Feature: Show changelog URL for each new detected versions #570

Open yvele opened 5 years ago

yvele commented 5 years ago

I could be nice for npm-check-updates in the interactive mode to display the changelog URL for each updated version, to ease user decision process 🤔

Originally posted by @yvele in https://github.com/tjunnone/npm-check-updates/issues/555#issuecomment-508802010

Yes, I agree this would be a nice feature!

Originally posted by @raineorshine in https://github.com/tjunnone/npm-check-updates/issues/555#issuecomment-508826303

Something like

$ ncu
Checking package.json
[====================] 3/3 100%

 express           4.12.x  →   4.13.x   https://github.com/expressjs/express/releases
 multer            ^0.1.8  →   ^1.0.1   https://github.com/expressjs/multer/blob/master/CHANGELOG.md
 react-bootstrap  ^0.22.6  →  ^0.24.0   https://github.com/react-bootstrap/react-bootstrap/blob/master/CHANGELOG.md

Run ncu -u to upgrade package.json

This is an example only to help you understand what I was suggesting. It's not a "real" example, maybe we want the full changelog in interactive mode.. This issue is not really the place to discuss that 😉

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 this

image

But 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.

raineorshine commented 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

brettz9 commented 4 years ago

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
yvele commented 4 years ago

@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:

  1. changelog/changelog.md
  2. history/history.md
  3. changes/changes.md
  4. If the repository is hosted on GitHub, show the GitHub release URL
  5. Same for GitLab releases?

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 😉

brettz9 commented 4 years ago

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.))

brettz9 commented 4 years ago

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...

Clement134 commented 4 years ago

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.

CreativeTechGuy commented 3 years ago

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.

raineorshine commented 3 years ago

@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.

CreativeTechGuy commented 3 years ago

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.

raineorshine commented 3 years ago

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.

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 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 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.

CreativeTechGuy commented 3 years ago

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. :)

Sparticuz commented 10 months ago

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

CreativeTechGuy commented 10 months ago

@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.

vassudanagunta commented 3 months ago

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.