You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a really cool library but bundling it for usage in a browser results in a massive bundle (146KB for a bundle containing only this library, post-minification, pre-gzip).
Optimizing it wouldn't be too hard and, even while it would require a tiny bit more work on the developers that use this library I believe it would be definitely worth it.
First optimization that can be done is not loading all locales at once but only those needed by the app. There are a couple ways you can do this:
By first registering the locale the app needs:
constcountries=require('i18n-iso-countries');countries.registerLocale(require('i18n-iso-countries/locales/en.json'));countries.getNames('en');// returns the list of names in englishcountries.getNames('fr');// throws "unknown locale, please register it first"
Or the date-fns way, where the locale object is used directly:
constcountries=require('i18n-iso-countries');consten=require('i18n-iso-countries/locales/en.json');countries.getNames(en);// returns the list of names in english
If you wish to keep the "all locales are pre-loaded" behavior on node, you can specify a different entrypoint for browsers than for node in package.json and have the node entrypoint register all locales then call the browser entrypoint.
Second optimization is getting rid of the pad dependency. The reason behind it is that this library is itself dependant on wcwidth, which itself is dependant on defaults, which itself uses clone.
That's a massive amount of code for something like pad, even more now that String.prototype.pad{Start|End} is standard and really easy to polyfill.
The best way to optimize this would be to simply use String.prototype.pad{Start|End} instead of pad, and add a note in the documentation stating that the environment needs to provide a polyfill for that function if it is not natively available. (core-js can provide these polyfills)
I can submit a PR with all this if you are interested.
Thank you :)
The text was updated successfully, but these errors were encountered:
This is a really cool library but bundling it for usage in a browser results in a massive bundle (146KB for a bundle containing only this library, post-minification, pre-gzip).
Optimizing it wouldn't be too hard and, even while it would require a tiny bit more work on the developers that use this library I believe it would be definitely worth it.
First optimization that can be done is not loading all locales at once but only those needed by the app. There are a couple ways you can do this:
If you wish to keep the "all locales are pre-loaded" behavior on node, you can specify a different entrypoint for browsers than for node in
package.json
and have the node entrypoint register all locales then call the browser entrypoint.Second optimization is getting rid of the
pad
dependency. The reason behind it is that this library is itself dependant onwcwidth
, which itself is dependant ondefaults
, which itself usesclone
.That's a massive amount of code for something like
pad
, even more now thatString.prototype.pad{Start|End}
is standard and really easy to polyfill.The best way to optimize this would be to simply use
String.prototype.pad{Start|End}
instead ofpad
, and add a note in the documentation stating that the environment needs to provide a polyfill for that function if it is not natively available. (core-js
can provide these polyfills)I can submit a PR with all this if you are interested.
Thank you :)
The text was updated successfully, but these errors were encountered: