Currently, users cannot rely on full i18n support to be present cross-platform and even cross-distribution mainly because different package maintainers use different configurations for ICU and if Node.js was built with system-icu one still has to have libicu installed. Browsers on the other hand generally do support full i18n out of the box.
There is the option to use the full-icu package but it is somewhat awkward to use as it requires a environment variable or commandline switch to work.
Building with full-icu is currently a ~40% increase binary size (on macOS, it goes from 35M to 49M). Is this an acceptable tradeoff? I'm thinking that if we build with it, ICU data should be moved in-tree so the build does not rely on external downloads.
cc: @nodejs/intl
Currently, users cannot rely on full i18n support to be present cross-platform and even cross-distribution mainly because different package maintainers use different configurations for ICU and if Node.js was built with
system-icuone still has to havelibicuinstalled. Browsers on the other hand generally do support full i18n out of the box.There is the option to use the
full-icupackage but it is somewhat awkward to use as it requires a environment variable or commandline switch to work.Building with
full-icuis currently a ~40% increase binary size (on macOS, it goes from 35M to 49M). Is this an acceptable tradeoff? I'm thinking that if we build with it, ICU data should be moved in-tree so the build does not rely on external downloads.cc: @nodejs/intl