Repository navigation
Building with full-icu by default #19214
Description
Activity
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.
Reacted by Daijiro Wachi, Vse Mozhe Buty, Nikita Skovoroda, Gibson Fahnestock, Adrian Wilkins, Ilya, Lucas Caton, Vlad, Mohammad Hossein Fattahizadeh, Jason Cooke and 20 more+1 to this, 35M to 49M is totally worth full i18n
Reacted by Mohammad Hossein Fattahizadeh, Daniel Iñigo, Jason Cooke, Andreas Bexelius, Ruben Nic, Patrick Pissurno, Scott Gibson, Sebastian Niemann, Timm Preetz, Artem Nechunaev and 33 moreReacted by Ricardo Tomasi-1
Reacted by Jiawen GengReacted by Mohammad Hossein Fattahizadeh, Scott Gibson, Sebastian Niemann, cevek, YCM Jason, Kamil Tomšík, Michael Hulet, Doug Moscrop, Cédric Marcone, Pietro Paolo Vismara and 15 more- One option is to get the full-icu package working without options. I need help getting the platform part to work.Reacted by Quentin Sommer and Oskar Larsson Högfeldt
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.
Reacted by snek, Nikita Skovoroda, Sindre Sorhus, Adrian Wilkins, Mike Andrzejewski, redpoptarts, Felix Becker, Andreas Bexelius, Scott Gibson, Sebastian Niemann and 12 moreAs long as we still have the ability to produce small-icu builds, my personal preference would be to build with full-icu by default.
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.
One option is to get the full-icu package working without options.
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).Reacted by snek, Ilya, Andreas Bexelius, Scott Gibson, Simon Schick, Artem Nechunaev and Nathan Woltmanusers first have to discover this package
it could be a checkbox in the installer to install… or a suggested package within ubuntu, etc
which must be carried by every application
couldn't it be deduped via npm?
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.
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.
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
ICU should be moved in-tree so the build does not rely on external downloads.
- ICU is already in-tree, but is specially trimmed to just have small data. Part of the size issue was repo size. So, one step could be include full data in the repo (Unless there's some other clever idea - subrepo? git LFS? lossy compression?)
- Then, make 'full' the default out of the repo when you do
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 onfull-icu.129 remaining items
Hopefully full-ICU will work with https://v8.dev/features/intl-numberformat.
Reacted by Steven R. LoomisCurrent 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 withlocaleargument which is not supported by current build.Well, full feature support is better.
Current version of Node.js does support
localeargument, but only supports English. This is tricky to check.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
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 withlocaleargument which is not supported by current build.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.
icudt64l.dat compression:
type Size % none 27,531,792 0% compress 16,359,873 68% gzip 11,007,314 60% bzip2 9,781,482 64% xz 6,669,432 76% Looks like bz2 is even in python 2.7 so may be worth while. (1.2Mb)
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.
The MDN compatibility table for these functions currently show "?".
Reacted by FUJI Goro, Steven, Niels de Bruin and Benjamin van der Burgh- added a commit that references this issue
on Jul 27, 2026
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