(In reply to Giovanni Campagna from comment #0)

> If building with system-icu (as it was done in the past) is not possible,
> nodejs should be built with full-icu, which will embed the whole data files
> in the binary.

OK, I suppose it's going to have to be full-icu, because system-icu in Fedora is still on 63.2 and Node.js requires 64.1.

I'll see what I can do.

It turns out that building with `full-icu` results in a huge increase in disk usage (70MiB on x86_64). That... doesn't seem appropriate to have for all deployments. We want to be able to retain a very small installation for container usage.

https://nodejs.org/api/intl.html#intl_providing_icu_data_at_runtime indicates that you can set an environment variable or pass `--icu-data-dir` to the node binary in order to have it read the unicode data. My plan is this: continue to build Node.js with `small-icu` and also ship a new subpackage 'nodejs-i18n' that will contain the data files in /usr/lib[64] (the 64 depends on if it's a 64-bit or 32-bit OS). To work with them, you'd run `node --icu-data-dir=/usr/lib64` or set `NODE_ICU_DATA=/usr/lib64` in the environment.

Will that work for you, Giovanni?

(In reply to Stephen Gallagher from comment #2)
> ship a new subpackage 'nodejs-i18n'

Please be careful about the subpackage name. It might one day collide with https://www.npmjs.com/package/i18n

(In reply to Stephen Gallagher from comment #2)
> It turns out that building with `full-icu` results in a huge increase in
> disk usage (70MiB on x86_64). That... doesn't seem appropriate to have for
> all deployments. We want to be able to retain a very small installation for
> container usage.
> 
> https://nodejs.org/api/intl.html#intl_providing_icu_data_at_runtime
> indicates that you can set an environment variable or pass `--icu-data-dir`
> to the node binary in order to have it read the unicode data. My plan is
> this: continue to build Node.js with `small-icu` and also ship a new
> subpackage 'nodejs-i18n' that will contain the data files in /usr/lib[64]
> (the 64 depends on if it's a 64-bit or 32-bit OS). To work with them, you'd
> run `node --icu-data-dir=/usr/lib64` or set `NODE_ICU_DATA=/usr/lib64` in
> the environment.
> 
> Will that work for you, Giovanni?

It's not a great solution. I should also point out that one can install the ICU data separately from NPM, so yeah a similar workaround is already possible without a new package.
The whole point of this bug, though, is that running "node" used to do the right thing, and now the command line needs to change. Especially for scripts and terminal usage this is quite painful.

Maybe the compromise is that the nodejs-i18n package also ships a profile.sh snippet to set the right environment variable? At least it would help with interactive, desktop usage.
Alternatively, can node be patched to always look for the data in the system directory, and fallback to the builtin US English data only if the package is not installed?

Getting this solved "the right way" is taking too much of my time. I'm going to go the "full-icu" route for now and we can try to optimize it if and when someone packages ICU 64.2 for Fedora.

OK, I lied. I've gone ahead and packaged a version of libicu 64.2 (see BZ#1766771, linked as blocking this BZ). Once that lands, I'll rebuild Node.js against it.

FEDORA-2019-dcd50aea78 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-dcd50aea78

FEDORA-MODULAR-2019-6f02daa6ca has been submitted as an update to Fedora 29 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-6f02daa6ca

FEDORA-MODULAR-2019-376858362f has been submitted as an update to Fedora 31 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-376858362f

FEDORA-MODULAR-2019-2aeb4c4522 has been submitted as an update to Fedora 30 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2aeb4c4522

nodejs-12.13.0-7.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-dcd50aea78

nodejs-12-2920191029011808.6c81f848 has been pushed to the Fedora 29 Modular testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-6f02daa6ca

nodejs-12-3020191029011808.a5b0195c has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-2aeb4c4522

nodejs-12-3120191029011808.f636be4b has been pushed to the Fedora 31 Modular testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-376858362f

nodejs-12.13.0-7.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

nodejs-12-3120191029011808.f636be4b has been pushed to the Fedora 31 Modular stable repository. If problems still persist, please make note of it in this bug report.

nodejs-12-3020191029011808.a5b0195c has been pushed to the Fedora 30 Modular stable repository. If problems still persist, please make note of it in this bug report.