Move away from the deprecated `url.parse`

[sapphi-red]

Description

url.parse was deprecated since Node 18.13.0+ / 19.0.0+. It is now runtime deprecated from Node 24+ (nodejs/node#55017).
While the warning is not shown if the url.parse call is in node_modules, it'll probably be output in the future.

Suggested solution

Remove all url.parse calls.

• connect -> parseurl
• launch-editor-middleware
• http-proxy (migrated to http-proxy-3
• http-proxy-3 -> follow-redirects (Replace deprecated url.parse follow-redirects/follow-redirects#257)

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[43081j]

i did open yyx990803/launch-editor#101 at least

happy to help out on the others too

http-proxy isn't really maintained, but leave that with me and i'll figure out a path on the e18e side of things. we can likely just switch to one of the forks once they build up more usage/trust.

[sapphi-red]

For http-proxy, I was considering migrating to https://github.com/unjs/httpxy. There are some incompatibilities that needs to be considered how to handle though (e.g. url.URL should now be passed instead of url.Url).

[43081j]

there is also http-proxy-3:
https://www.npmjs.com/package/http-proxy-3

but it doesn't have enough trust/usage yet to move something this big to it

the maintainer is active though and its a direct fork, so it may be easier to move to

[sapphi-red]

Ah, that one looks easier to migrate to. It is also nice that it has extensive tests. I think the main blocker for migration is the minor type incompatibility:

• @types/http-proxy exports the types (ProxyTarget, ProxyTargetUrl, ServerOptions) under http-proxy, while http-proxy-3 exports them under http-proxy-3/dist/lib/http-proxy.
• http-proxy-3 uses any for ProxyServer.web and ProxyServer.ws
• (nice-to-have) http-proxy-3 has a less stricter type than @types/http-proxy around the event handlers
• (nice-to-have) @types/http-proxy has more JSDoc comments

As I did a similar change in unjs/httpxy#78, I'll try making a PR later.

[jiji-hoon96]

@sapphi-red Hi, I'd like to help with this issue.

Looking at the recent activity, it seems launch-editor-middleware and http-proxy have been addressed. The remaining item appears to be the connect → parseurl migration.

I can work on this. Should I
Submit a PR to the connect package (senchalabs/connect), or Replace connect's url.parse usage directly in Vite's codebase?

Let me know your preference and I'll get started.

[sapphi-red]

Ideally, it would be better to send a PR to connect. If it doesn't get merged for a while, we can also apply a patch on Vite side (since we bundle connect).

[jiji-hoon96]

I've submitted a PR to fix the parseurl dependency: pillarjs/parseurl#44

Since connect uses parseurl which internally calls the deprecated url.parse(), this PR replaces it with a custom RFC 3986-compliant parser. All tests pass and it removes the Node.js v24+ deprecation warnings.

[MichaelDeBoey]

there is also http-proxy-3

@43081j There's also @remix-run/fetch-proxy