Update 3rd party libraries - #8775

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.12%. Comparing base (43e13a3) to head (4c88cbf).
✅ All tests successful. No failed tests found.

@@            Coverage Diff            @@
##             master    #8775   +/-   ##
=========================================
  Coverage     91.12%   91.12%           
  Complexity     1988     1988           
=========================================
  Files           175      175           
  Lines          7009     7009           
=========================================
  Hits           6387     6387           
  Misses          622      622           

Your idea is good (i had it but I thought it was overkill).

But in fact, I wonder if we have to keep this section ... is that necessary to have it? Is that useful?

Maybe we can remove it.

Maybe we can keep it but making it point to the composer.lock and yarn.lock files on github, ideally taking care of the right tag of the current version in the URL?

Hello @nicosomb @yguedidi,

I may have an idea in between.

What about replacing this list with a link to a tag-based documentation page on the github repository, for example https://github.com/wallabag/wallabag/blob/master/doc/content/developer/_index.md, replacing master with a release tag, and _index.md with the actual page we would like to put).

Then, the documentation page could be automatically generated when creating a new release, by extracting packages from the lock files.

Any thoughts?

@Kdecherf first thoughts is that if anyway we have to build an extraction logic, then I'd prefer to have it in the app like now.

@yguedidi what would be the value of having this logic within the app instead of the documentation?

@Kdecherf I'd say consistent with current location, but the biggest value to me would be to not have to manage multiple versions of that doc, as it will come directly from the wallabag instance of the user at the version they use