Skip to content

Change code to use url.URL instead of url.parse #1254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
watson opened this issue Aug 2, 2019 · 6 comments · Fixed by #1340
Closed

Change code to use url.URL instead of url.parse #1254

watson opened this issue Aug 2, 2019 · 6 comments · Fixed by #1340

Comments

@watson
Copy link
Contributor

watson commented Aug 2, 2019

url.parse is a deprecated core API. We should update our code to use url.URL instead.

watson added a commit to watson/apm-agent-nodejs that referenced this issue Aug 14, 2019
We can't upgrade to the new version of 'standard' currently because we
still use the deprecated `url.parse` API in several locations (see issue
no elastic#1254). But to ensure fewer merge conflicts between the 2.x and the
upcoming 3.x branch), we'll fix as many future linting issues as
possible already now.
watson added a commit that referenced this issue Aug 14, 2019
We can't upgrade to the new version of 'standard' currently because we
still use the deprecated `url.parse` API in several locations (see issue
no #1254). But to ensure fewer merge conflicts between the 2.x and the
upcoming 3.x branch, we'll fix as many future linting issues as
possible already now.
@yuxizhe
Copy link
Contributor

yuxizhe commented Sep 4, 2019

@watson I'm happy to take this issue.

@watson
Copy link
Contributor Author

watson commented Sep 4, 2019

@yuxizhe that would be really helpful. But it might be a bit tricky though... before I opened this issue, I checked if I could easily do it myself. But it's unfortunately not a 1-to-1 replacement due to the differences in how the two functions behave. But we can discuss how to best implement it if you still want to take it on

@yuxizhe
Copy link
Contributor

yuxizhe commented Sep 4, 2019

@watson Yes, I reread the docs https://nodejs.org/api/url.html#url_url_strings_and_url_objects.

I search in this repo find there are a few places where we use url.parse, most of them are just use .pathname propertie. Because URL and UrlObject both have .pathname propertie, so I think in these places they can be easily replaced.

Except for the code in

// NOTE: This will also stringify and parse URL instances
// to a format which can be mixed into the options object.
function ensureUrl (v) {
if (typeof v === 'string') {
return url.parse(v)
} else if (v instanceof url.Url) {
return v
} else if (url.URL && v instanceof url.URL) { // check for url.URL because it wasn't added until Node.js 6.13.0
return url.parse(v.toString())
} else {
return v
}
}

Object.assign(options, ensureUrl(arg))

Object.assign(options, URL) mix options with URL in a different format

{ [Symbol(context)]:
   URLContext {
     flags: 912,
     scheme: 'https:',
     username: '',
     password: '',
     host: 'aaa.com',
     port: null,
     path: [ 'a', 'b' ],
     query: 'a=1',
     fragment: null },
  [Symbol(query)]: URLSearchParams { 'a' => '1' } }

So in this place I won't simply replace it with URL,
what about the code below:

function formatURL (item) {
  return {
    href: item.href,
    pathname: item.pathname,
    protocol: item.protocol,
    host: item.host,
    port: item.port,
    hostname: item.hostname,
    hash: item.hash,
    search: item.search,
  }
}
// NOTE: This will also stringify and parse URL instances
// to a format which can be mixed into the options object.
function ensureUrl (v) {
  if (url.URL && (v instanceof url.URL || typeof v === 'string')) {
    const urlItem = new URL(v.toString())
    return formatURL(urlItem)
  } else if (typeof v === 'string') {
    return url.parse(v)
  } else {
    return v
  }
}

@yuxizhe
Copy link
Contributor

yuxizhe commented Sep 6, 2019

Oh, there is another problem. Relative URLs in WHATWG URL API nodejs/node#12682

I prefer to use this one new URL('/a/b', 'relative:///');

@watson
Copy link
Contributor Author

watson commented Sep 10, 2019

Oh nice, I didn't know you could put in relative:/// - I just thought we would put in http://localhost or something like that. But I like relative:/// more 👍

@watson
Copy link
Contributor Author

watson commented Sep 10, 2019

I think your approach in the code you posted above is good. If you can throw together a PR we can take it from there 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants