> Now imagine 30 years from

For the javascript ecosystem this is already true for projects that are > 2 year old.

Not kidding, try to build a 2 year old React web application, you'll see what I mean.

TBF, part of the problem is that dependency locking only caught on recently. (Yarn came out in 2016.) That makes it more possible.

So... don't do that.

There are plenty of options that have a reasonable probability of being stable.

(Also, consider committing the docs right in to the repo. In the 1970s such an idea would have been absurd. Today, a lot of my projects technically already have this, thanks to vendoring and docs embedded into the programs themselves.)

best documentation is getting the business logic mapped out and the code itself, along with data mapped-out with what does what to it when and how. As any code documentation will be out of date in way way or another, even best sites it will be case of getting that documentation and then mapping a few decades worth of change management, bug tracking and other avenues that modified that code.

I will say though, every migration project I worked up, the documentation was carefully worded in the contract as being the customers liability and with that, code gets migrated logic for logic, bug for bug and testing so anal that it will show that what goes in is the same that comes out in the migrated code. That and the business documentation will still be good, even much of the code documentation if high enough level, but the code itself will be the best documentation.

Until we get a standard in which the documentation produces the code and all changes done to the documentation over quickly hacking the code, the disparity between any documentation and the code will always be adrift.

So you see many bespoke solutions to go thru the code and produce documentation from that to varying levels of success, however that success for one sites quirks in code may not work as well with others.

Hence even the best documentation will wisely get treated with a pinch of salt and in many instances, be like comparing a book to the movie it spawned in many ways, some close to the original, many not even close. That is documentation and code in a nutshell.

Always best to map the data first and that can be done easier and more automated, more so databases and generating a schema and then map what code talks with what and gradual get to see what is happening.