Repository navigation
Building with full-icu by default #19214
Description
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
Activity
jasnell commentedon Mar 7, 2018
The binary size has always been the key issue with ICU, particularly on resource constrained devices where Node.js is expected to run. As long as we still have the ability to produce small-icu builds, my personal preference would be to build with full-icu by default.
devsnek commentedon Mar 8, 2018
+1 to this, 35M to 49M is totally worth full i18n
mscdex commentedon Mar 8, 2018
-1
devsnek commentedon Mar 8, 2018
@mscdex can you elaborate? i assume you're -1 because of binary size?
srl295 commentedon Mar 8, 2018
srl295 commentedon Mar 8, 2018
#3460
mscdex commentedon Mar 8, 2018
@devsnek Yes.
TimothyGu commentedon Mar 8, 2018
I'm also -1 on this for the same reason as @mscdex. I'd rather find a way to fix #3460 instead.
bnoordhuis commentedon Mar 8, 2018
I was strongly against full-icu when ICU was introduced but I've since made a 180 flip. Ease of use and being able to rely on it just being there outweigh the downside of a bigger binary.
The binary size doesn't particularly trouble me anymore. If that was really an issue we would build without debug symbols or make them available as a separate download, but we don't.
Bigger runtime memory footprint is something that should be checked. ICU is pretty parsimonious though, what I know of it.
silverwind commentedon Mar 8, 2018
Yes, building the smaller variants should still be an option. Thought, I don't see platforms where a few MBs more are an issue as the primary consumers for Node.js.
That would be an improvement, but it's still an issue that users first have to discover this package, probably after wondering why i18n APIs don't work like they do in browsers.
As a package author, I'm reluctant to include
full-icuas dependency because of application size concerns (which must be carried by every application as opposed to once if it were built into Node.js).srl295 commentedon Mar 10, 2018
@silverwind
it could be a checkbox in the installer to install… or a suggested package within ubuntu, etc
couldn't it be deduped via npm?
I wasn't trying to do a bait and switch :) full by default I like for many reasons, simplicity, cultural-linguistic correctness, dropping the words 'English only' from the vocabulary , etc.. But I do understand that the size issues are real. Not insurmountable but real.
devsnek commentedon Mar 10, 2018
the way i see this, node has been working with negative size constraints because it was always missing full-icu. i build with full-icu everywhere anyway and like @silverwind said the primary consumers of node are not the people who can't download 40mb binaries. that being said, we can still keep our small-icu builds and just add full-icu builds
srl295 commentedon Mar 12, 2018
configure && make(Ideally, packagers and other users should be specifying --with-intl ( none, full-icu, small-icu ) already and so this only affects the default.One option as far as download could be to have two sets of downloads (small and full). That means complexity for the build and website project, though.
Some statistics:
full-icu gets 47k downloads a month, the underlying data package icu4c-data 41k a month. In Github, 112 repos and 45 packages depend on
full-icu.129 remaining items
gengjiawen commentedon Aug 29, 2019
Hopefully full-ICU will work with https://v8.dev/features/intl-numberformat.
libook commentedon Sep 6, 2019
Current version of Node.js does support
localeargument, but only supports English. This is tricky to check.How about this idea:
For developers who expect to get the same browser-like results on Node.js(I am one of them);
shows a warning message while calling methods with
localeargument which is not supported by current build.Well, full feature support is better.
srl295 commentedon Sep 6, 2019
It's better than that. It's not just English. Please see https://nodejs.org/api/intl.html#intl_providing_icu_data_at_runtime
There's no API that tells you what the exact situation is. However, there are internal parameters that will indicate that, as well as results returned by https://www.npmjs.com/package/full-icu ( the package ) or https://github.com/srl295/btest402
There will always (well, at least for a long long time) be content not supported by the current build. The Torwali language isn't yet supported for example, so
trwwon't be supported. So I don't think a warning is needed.I think the best is to make it easier to get 'full icu' to more people. And so I'm working on a PR for this issue.
mhdawson commentedon Sep 6, 2019
@srl295 thanks and looking forward to the PR.
srl295 commentedon Sep 12, 2019
icudt64l.dat compression:
Looks like bz2 is even in python 2.7 so may be worth while. (1.2Mb)
GitTom commentedon Oct 29, 2019
I tested v13.0.1 on Windows and found that Date.toLocaleString (and related) now respect their parameters and produce expected results (they do not on v12), so I created a PR on the repo for MDN's compatibility data.
mdn/browser-compat-data#5068
The MDN compatibility table for these functions currently show "?".
tools: support full-icu by default