I'm a full-stack software developer working in the financial sector, their statement is factual.

Companies will never want to take on liability that has the potential to bankrupt them. It is in their best interest to not reveal the version of libraries they are using as some versions may have publicly known vulnerabilities, and it would make it incredibly easy for attackers to build an exploit chain if they knew the exact versions being used.

Securing client code is just as important as securing server code, as you don't want to expose your users to potential XSS attacks that could affect the way the page gets displayed, or worse, leak their credentials to a third party. If this happened in the EU or some parts of Canada, and it's been found that the company reduced their threat model "for the sake of openness", they would likely be fined into bankruptcy or forced to leave the market.

Unfortunately, this is one of those cases where your interests and ethics will never be aligned with those of service owners as they are held to a certain standard by privacy laws and other regulations.

No need to get aggravated, I completely grasp it, you've possibly misunderstood or not entirely read my comment if that's your takeaway.

I'm not talking about server code specifically, I'm going through the stages between the source code repo(s) and what your browser ends up receiving when you request a site.

NodeJS is relevant here because it's what runs nearly all major JS bundlers (webpack, vite, etc), which are what produces the code that ultimately runs in the browser for most websites you use. Essentially in a mathematical sense, the full set of dependencies for that process are a part of the input to the function that outputs the JS bundle(s).

I'm not really sure what you mean with that last part, really, anyone hosting something on the internet has to care about that stuff, not just businesses. GDPR can target individuals just as easily as for-profit companies, it's about the safety of the data, not who has it—I'm assuming you would not want to go personally bankrupt due to a deliberate neglect of security? Similarly, if you have a website that doesn't hit the performance NFRs that search engines set, no one will ever find it in search results because it'll be down on page 100. You will not be visiting websites which don't care about this stuff.

Either way, all of that is wider reasoning for the main point which we're getting away from a bit, so I'll try to summarise as best I can:

Basically unless you intend your idea to only work on entirely open source websites (which comprise a tiny percentage of the web), you're going to have to contend with these JS bundles, which as I've gone into, is basically an insurmountable task due to not having the complete set of inputs.

If you do only intend it to work with those completely open source websites, then crack on, I guess. There's still what looks to me like a crazy amount of things to figure out in order to create a filter that won't be able to work with nearly all web traffic, but if that's still worth it to you, then don't let me convince you otherwise.

Edit: typo