i18next / i18next-http-backend

i18next-http-backend is a backend layer for i18next using in Node.js, in the browser and for Deno.
MIT License
443 stars 67 forks source link

BREAKING CHANGE: drop support for XMLHttpRequest and remove cross-fetch #144

Open talentlessguy opened 2 months ago

talentlessguy commented 2 months ago

This PR removes support for XMLHttpRequest as it is not used widely anymore for fetching things. Fetch API no longer requires a polyfill on Node.js, and is supported by all major browsers and runtimes.

See compatibility table: https://developer.mozilla.org/en-US/docs/Web/API/fetch#browser_compatibility and: https://caniuse.com/fetch

For environments that don't support fetch (such as IE11) - they should install a fetch polyfill in their projects.

It also removes dependency on cross-fetch as it is not needed anymore. Node.js supports fetch natively since 18.x. I've added an engines.node field to notify that minimum node 18 is required.

Since it's a breaking change, in my opinion a semver major bump is required.

Checklist

Checklist (for documentation change)

adrai commented 2 months ago

XMLHttpRequest is only used as fallback... if no fetch is available... Also cross-fetch is only used if fetch is not available... At runtime there should be no difference on modern environments of having or not having the XMLHttpRequest and/or cross-fetch "logic" in i18next-http-backend or not... So what hurts in keeping i18next-http-backend like is it now for a longer while?

talentlessguy commented 2 months ago

@adrai unnecessary code being downloaded by browsers and package managers. Other packages might also import cross-fetch but with another version, resulting in dependency duplication.

adrai commented 2 months ago

Do you have an actual issue with the current i18next-http-backend version? Do you need to have this merged soon? Because of what?

talentlessguy commented 2 months ago

@adrai there's no urgency of it getting merged, I just submitted a PR as a general ecosystem cleanup. That's done so that modern environments aren't slowed down by unnecessary polyfills.

adrai commented 2 months ago

My concern is, I know there are users out there having still the need for this fallbacks... if I merge this now, there risk is high there will be more github issues, etc... asking for bringing back support etc... Would you be ready to respond to those github issues?

adrai commented 2 months ago

@adrai there's no urgency of it getting merged, I just submitted a PR as a general ecosystem cleanup. That's done so that modern environments aren't slowed down by unnecessary polyfills.

ok, then let's keep this PR open for a while...

talentlessguy commented 2 months ago

@adrai

1) in case of fallbacks, they should pin a version to the previous major. This is very simple, just doing a ^major... works. Stuff might break only if it's imported without specifying a version, which is a risk of it's own anyway. Any further bugfixes can be backported to previous major if needed, in case there's an urgent security bug. 2) I labeled it as "BREAKING CHANGE" specifically for preserving compat, so that other projects who don't need all these fallbacks and polyfills (which are the majoeity) don't have to download/pull the code. 3) yes, I'm ready to fix it if there's any issues arising with it.

adrai commented 2 months ago

will come back to this in 6-7 months...

talentlessguy commented 2 months ago

@adrai thanks for reaching out and taking time to look at the PR! I'll ping in 6 months in case of anything