Hey @jiji-hoon96! Thanks for investing time and effort in helping the project! ❤️

You are right the url.parse() seems deprecated:

var url = require('url')
var parse = url.parse 
console.log(parse('https://expressjs.com/en/4x/api.html#req.protocol'))

(node:4158863) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.
(Use `node --trace-deprecation ...` to show where the warning was created)

I was wondering if you explored the option to use the URL constructor directly like:

var data = new URL('https://expressjs.com/en/4x/api.html#req.protocol');
console.log(data);

The output is quite similar, but as mentioned here (url.parse supports a few use cases that are not supported with new URL().) not sure about the final impact for us.

// url.parse()

Url {
  protocol: 'https:',
  slashes: true,
  auth: null,
  host: 'expressjs.com',
  port: null,
  hostname: 'expressjs.com',
  hash: '#req.protocol',
  search: null,
  query: null,
  pathname: '/en/4x/api.html',
  path: '/en/4x/api.html',
  href: 'https://expressjs.com/en/4x/api.html#req.protocol'
}

//new URL()
URL {
  href: 'https://expressjs.com/en/4x/api.html#req.protocol',
  origin: 'https://expressjs.com',
  protocol: 'https:',
  username: '',
  password: '',
  host: 'expressjs.com',
  hostname: 'expressjs.com',
  port: '',
  pathname: '/en/4x/api.html',
  search: '',
  searchParams: URLSearchParams {},
  hash: '#req.protocol'
}

The regex you proposed in your parser seems to follow a linear complexity, but I prefer to avoid include custom implementations if we can use built-in utils or existing APIs.

wdyt @blakeembrey?

Thanks for the suggestion! You're right - using the URL constructor is a better approach than a custom implementation. I'll update the code to use new URL() instead. 👍

ref: nodejs/web-server-frameworks#71

Given the constraints, I believe is the best available option because

• It removes the deprecation warnings (the main issue)
• It uses Node.js built-in APIs as you prefer

However, I'm open to any direction you'd prefer. Should we

• Keep the current WHATWG URL approach?
• Go back to the custom parser?
• Wait for a potential TolerantURL API in Node.js core?

Let me know your thoughts! 🙏

Proposal: Modernizing parseurl by Embracing Native Node.js APIs

Hello everyone,
I've been following the critical discussion around managing URL parsing in this package, particularly the need to address the deprecated url.parse method (as referenced in PR #44).
I'd like to propose a solution that leverages modern Node.js features while preserving the package's existing API contract, making the transition seamless for its extensive user base.
The Core Proposal: Plain Object URL Representation
The key change is to shift the implementation internally to use the native URL class but have parseurl return a plain JavaScript object with properties matching the expected URL structure.
This approach resolves our technical debt while maintaining stability:

• Eliminates Deprecation Warnings: We stop using the deprecated url.parse method, resolving the primary technical issue.
• Utilizes Built-in APIs: We lean on Node.js's optimized, modern URL constructor, which is generally preferred over custom parsing logic.
• Retains Current API Structure: The returned value is explicitly not an instance of url.Url or global.URL, but a simple data object. This ensures consumers relying on direct property access will not break.

Implementation Preview

I have worked on a draft implementation of this change:

• Proposed index.js Implementation:::https://github.com/raji-mahmud-a/parseurl/blob/master/index.js

Impact Analysis: Backward Compatibility is Key
Given that Express.js accounts for about 90% of this package's weekly downloads, stability is paramount.

This update is designed to be fully backward compatible. Because the output retains the expected API structure as a plain object, existing consumers of the package should not require any modifications, ensuring a smooth transition for the entire ecosystem.

Critical CI/CD Pipeline Fixes

In parallel with the feature update, I've addressed critical maintenance issues in the existing CI/CD workflow (ci.yml) to ensure reliable testing on modern GitHub Actions runners:

CI/CD Fixes Implementation

• Proposed ci.yml Workflow Fixes::: https://github.com/raji-mahmud-a/parseurl/blob/master/.github/workflows/ci.yml

I'll like to know what you think.
Thanks.

@UlisesGascon @bjohansebas

Thank you for the constructive feedback!

I have updated the PR to address the comments and fix the CI failures:

1. Dropped Legacy Support: Removed Node.js 0.8, 0.10, and 0.12 from the CI matrix as suggested.
2. Updated CI Workflow: Upgraded GitHub Actions (checkout, setup-node) to v4 and fixed the deprecated set-output syntax.
3. Fixed Typo

The CI checks are now passing. Ready for review!

Nice 💜,

To remove the deprecated url.parse() method, I suggest removing all instances of url.Url or new URL() and converting it to a plain object and this makes it considerably faster since there is no object construction

parseurl+1.3.3.patch
I know i could've done a pull request for this fix but the short solution i used was to patch it. Here i share the patch for you guys so you can easy implement my changes and the deprecation uses the new WHATWG URL API

i hope it helps