TooTallNate / superagent-proxy

superagent-proxy v3 cannot be used with proxy-agent v6 because of breaking changes in the exports, at least.

var proxyAgent = require('proxy-agent');

https://github.com/TooTallNate/proxy-agents/tree/main/packages/proxy-agent

Perhaps that is what has been declared, but I'm not sure how to untangle this from the supposedly necessary proxy-agent upgrades for vm2.

Can there please be a v4 released that correctly imports proxyAgent v6?

proxy-agent has now been updated to remove the vm2 dependency. Is a release of superagent-proxy planned to integrate this update?

@TooTallNate You seem to be listed as the only collaborator in the npm page so I'll direct this at you, any chance of a review of this PR or an independent update? I'm wondering if we should consider this library unsupported at this point.

I suspect I speak for others when we say that we appreciate your other work on the proxy-agent -> .. -> degenerator stack but other dependencies referencing this lib hit kind of a dead end (without more drastic measures like migrating off this lib entirely).

As a workaround you can use the overrides prop of package.json to force an updated version of proxy-agent, nesting your dependencies if needed, in my case :

	"overrides": {
		"@nestjs-modules/mailer": {
			"inline-css": {
				"remote-content": {
					"superagent-proxy": {
						"proxy-agent": "^6.3.0"
					}
				}
			}
		}
	},

Seems to work fine for me. You may need to delete your package-lock.json.

Thanks @gterras but my experience has been that the overrides does not cascade. So if I create a library that points at superagent-proxy using overrides and someone uses my library they will still have the security issue (e.g. other lib -> my lib -> superagent-proxy === audit failure). Telling callers of my lib to apply overrides to their package is an unsatisfying solution.

The package.json docs are fairly vague on this point so it was discovered through trial and error.

Thanks @gterras but my experience has been that the overrides does not cascade. So if I create a library that points at superagent-proxy using overrides and someone uses my library they will still have the security issue (e.g. other lib -> my lib -> superagent-proxy === audit failure). Telling callers of my lib to apply overrides to their package is an unsatisfying solution.

Ha yes it might be more complex or even impossible regarding lib publishing.

People Who Know Things, I could use eyes and help on #50 where I think we can see the upgrade blockers more clearly now.

My experience with the overrides workaround:

✅ it will install the updated version for proxy-agents to node_modules
✅ it will silence the security audit warning
😭 it will break your intended use of .proxy(proxy_url) in your application

The superagent agent will not be configured to perform comms through a proxy.

Hi @TooTallNate, so will there be a newer version for this package or not ? Could you please clarify it ?

Latest versions of proxy-agent upgraded because of vm2 vulnerability are incompatible here