Publishing lock files of running services would be a big security risk for the service owner as it gives an easily parsable way for an attacker to check if your bundle includes any package versions with vulnerabilities.

You then also have tools like snyk used by many big organisations which has the ability to patch dependencies before the actual dependency published the patch themselves. This would lead to a version not corresponding with the bundled code.

In fact given bundling is pretty ubiquitous, but infinitely configurable at this point, even validating the integrity of the bundle Vs the versions in a lock file is a problem that will be hard to achieve. It’s kinda like wanting to untoast bread.

Also given many JS projects have a lock file which describes both the deficiencies of the front end bundle, server & build tooling, there is a risk of leaking information about that too (it’s best practice to make as little as possible about your server configuration publicly viewable)

IMO, the solution to this problem today is to use a modern, updated browser that sandboxes execution, run a adblocker with appropriate trusted blocklists for what you’re avoiding, try to only use sites you trust & if you can, push web developers to use CSP & SRI to prevent malicious actors from injecting code into their sites without them knowing. Many sites already take advantage of these features, so if you trust the owner, you should be able to trust the code running on the page. If you don’t trust the owner with client side JS, you probably shouldn’t trust them with whatever they’re running on the server side too.