Hello. You should be able to add your own polyfills.
This might be a good candidate: https://www.npmjs.com/package/url-polyfill

I'm aware that we could locally polyfill this (see considerations) within our app, but since this is a supported API across all common JavaScript implementations (see provided link) I think it would benefit NativeScript to provide the polyfill.

My reason for saying this is: as more pure JS libraries start to use this API those libraries will be unusable within a NativeScript app without people patching webpack (or their apps) with their own polyfills.

The provided library would not be a good fit for NativeScript since it uses the DOM to fill the gap to create a "valid" href link: see https://github.com/lifaon74/url-polyfill/blob/master/url-polyfill.js#L297

The polyfill mentioned within the referenced Mozilla Developer Docs would likely be a better fit: core-js

@rigor789 How does the NativeScript team feel about polyfilling something like this in core? Would they be open to a PR? Or is the recommended course for the end user to polyfill it themselves when needed?

@prestopasto I'm for it personally, but we'll need to discuss on the next TSC meeting. Perhaps a good initial step would be to do the polyfill in a plugin that uses the webpack plugin api to automatically set things up (https://docs.nativescript.org/webpack.html#plugin-api) and if it's something we all agree should be in core, we'll have a clear path from the plugin to core.

@rigor789 Thank you for the feedback and direction! I'm hoping to get some time to play with it soon.

@prestopasto one thing we're discussing as well is doing the URL parsing the same way Node does (as of recently) using Ada in c++ and possibly provide it in the runtime itself instead of core.

https://github.com/ada-url/ada

Personally I would not want that enabled by default. URL polyfills are pretty big and not that commonly use. Think an opt in option in our webpack setup would be best

Recent nativescript (version 8.8.x) seems to have something native on global.URL, but it's buggy as hell.
Doesn't work with a present but undefined variable as 2nd parameter, adds query parameters to pathname on parsing, not sure what else goes wrong.

Could we please either get it fixed or get rid of it?

@ray007 please open a new issue with an example, newer versions use ada for URL and it should be spec compliant. Also make sure you don't have an old polyfill replacing it.

Closing this one, as it's now shipped with the NativeScript runtimes:

• feat: URL & URLSearchParams ios#234
• feat: URL & URLSearchParams android#1801

My own polyfill works fine (and is not that large), so I'll just overwrite the native object.
I can live with buggy upstream URL.

@ray007 I'm the author of Ada URL parser. Can you share a reproducible bug report? I'm more than happy to investigate.

@ray007 we want to make sure it's working as expected, but as @anonrig said we need a reproducible example of an issue for it to be actionable on our side.

"buggy as hell" isn't actionable I'm afraid.

I already mentioned 2 cases in my description, which should be very simple to verify:

1. try new URL(absStringUrl, undefinedVar) - does not create a valid URL
2. try parsing a complete url with pathname and query parameters, the pathname property of the url will contain the query (with %3F instead of ?), and the query property will be empty.

Thanks for test cases, we'll make sure these work as expected.

@ray007 I fixed both of the issues, we'll have these in a release soon, thanks for pointing them out.

• fix(URL): allow undefined 2nd args and fix pathname return value ios#263
• fix(URL): allow undefined 2nd args android#1826