break Intl.js into a set of polyfills

[caridy]

trafficstars

now that we have full support for Intl in all evergreen browsers, it is time to break this down into small pieces, so users can patch their runtime in any way they want. E.g.: DateTimeFormat.prototype.formatToParts which is only in FF at the moment.

Proposal 1

• we can have a foundational bundle (which defines utilities, locale-data, etc).
• each individual feature is a polyfill on its own (e.g.: DateTimeFormat.prototype.formatToParts), and can use pieces from the foundational bundle (it is ok if we use IntlPolyfill.__internals or something along those lines).
• polyfill service can use dependencies, which means people asking for DateTimeFormat.prototype.formatToParts polyfill will get the foundational bundle plus the formatToParts polyfill.

Proposal 2

• we can have a foundational bundle (which defines utilities, locale-data, etc).
• each individual member of Intl to be a polyfill on its own (e.g.: NumberFormat), and can use pieces from the foundational bundle (it is ok if we use IntlPolyfill.__internals or something along those lines).
• polyfill service can use dependencies, which means people asking for DateTimeFormat polyfill will get the foundational bundle plus the DateTimeFormat polyfill.

I think proposal 1 is more compelling on the long run, but I will like to hear some suggestions here.

[daKmoR]

any progress on that?

Intl work pretty nicely on most browsers now... but e.g. formatToParts is still widely unsupported.. would be nice if there was a way to only load this.

2 Questions arise:

1. can we somehow access the local-data that is shipped with the browser?
2. currently load all of Intl.js still does not enables formatToParts [I guess it checks if Intl is available and if it is it does not load anything at all?]

[caridy]

any progress on that?

no, we need a brave soul here!

Intl work pretty nicely on most browsers now... but e.g. formatToParts is still widely unsupported.. would be nice if there was a way to only load this.

@zbraniecki and other mozilla folks are keeping separate polyfills for those, and they are also trying to keep this one up to date, but it is difficult.

can we somehow access the local-data that is shipped with the browser?

no

currently load all of Intl.js still does not enables formatToParts [I guess it checks if Intl is available and if it is it does not load anything at all?]

correct, that's why we want to split this into pieces where each piece does feature detection and patch what's needed. the tricky part is that formatToParts requires to load the whole Intl because it has to do the same thing under the hood. So, you're best chance at the moment is to force the polyfill to be applied in browsers that do not support formatToParts

[daKmoR]

puhh so you can't polyfill a single function alone... :/ that's rather frustrating... so for ~200 lines of code (formatToParts function) I would need to load all of Intl PolyFill + needed locales? [even if Intl incl all locales are already "available" in the browser]... // also imagine have 2 different version of locales :/

Loading around ~60kb extra - puh a tough sale...

is there absolutely no way to access the build in local-data from the browser? e.g. in some format like /locale-data/json/en.json - that would probably enable some "workaround"...

PS: just thinking out aloud here

[zbraniecki]

is there absolutely no way to access the build in local-data from the browser?

Nope, and for a good reason. First of all, ECMA402 is not bound to CLDR. It's perfectly possible and intentionally available to use a different database. It's not very easy to do right now, and we use CLDR dataset as a good reference implementation, but I think people would be very opposed to try to standardize CLDR as "dataset available from the userland" in case someone wants to implement JS engine with a different dataset that has the same data, but stored and represented differently.

Then, once you overcome this impossibility, you're hitting the wall with CLDR versions being updated and resulting models changing between CLDR versions. You'd have to write your code to be ready to handle structures from 29, 30, 31 and 32 and keep updating it while keeping the backwards compatibility.

Once you overcome those two impossibilities, then you have to agree on how to return the data. JSON? XML? Single huge table with all the data? Smaller tables? Well, those are changing between versions.

Standardizing an API to expose CLDR data is a nested impossibility.

source: I tried - https://bugzilla.mozilla.org/show_bug.cgi?id=1280654#c0

[daKmoR]

@zbraniecki thx for this detailed explanation - sadly it makes sense... sadly because it means creating a small polyfill for only formatToParts will probably be "impossible"...

[ghostd]

Hi @caridy,

I could spend some spare time on this issue if you are not in a hurry :)

I think i understood the purpose, but i'm not sure i got the way to go.

What should be the API of the polyfill?

import {polyfill} from 'datetimeformat/formatToParts';

polyfill(IntlObjectToBeAugmented);
// now we can use the function
dateFormatter.formatToParts(new Date());

Any advices? :-)

[longlho]

For those who are still following this thread, we've released a standalone version of Intl.NumberFormat here that also includes ES2020 features.

~~We're in the process of building~~ We've released Intl.DateTimeFormat ES2020 version as well.