Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ICU in embedded v8 #1968

Closed
zekth opened this issue Mar 19, 2019 · 32 comments
Closed

Add ICU in embedded v8 #1968

zekth opened this issue Mar 19, 2019 · 32 comments
Labels
cli related to cli/ dir feat new feature (which has been agreed to/accepted) web related to Web APIs
Milestone

Comments

@zekth
Copy link
Contributor

zekth commented Mar 19, 2019

As seen in #1952 / #1636 ICU needs to be added in Deno build.

Switching this flag to true maybe: https://github.com/denoland/deno/blob/master/.gn#L50 ?

ref: https://v8.dev/docs/i18n

@ATheCoder
Copy link
Contributor

ATheCoder commented Apr 11, 2019

I've been working on this for the past week and here is what I got so far.

Compiling Deno with chromium's ICU:

  1. Change the flag of v8_enable_i18n_support to true in the .gn file
  2. clone chromium's ICU from git clone https://chromium.googlesource.com/chromium/deps/icu to `deno/third_party/
  3. checkout ICU to the version specified in Deno's v8's DEPS file.
  4. build deno

What happens here is that when you want any IANA date's you get the following error:

<unknown>:1:11
new Date().toLocaleString("en-US", {timeZone: "America/New_York"});
           ^
Uncaught RangeError: Invalid time zone specified: America/New_York
    at <unknown>:1:12
    at evaluate (js/repl.ts:87:34)
    at replLoop (js/repl.ts:145:13)

So I did a little bit of debugging inside v8 and ICU and I found out that there is a C++ Error coresponding to U_MISSING_RESOURCE_ERROR.
I did a little bit of googling I found this FAQ of ICU.

What this means is that there are some kind of data for the ICU which it uses to load different time zones and etc. However those are not found here. (There is a data folder inside chromium's ICU (/deno/third_party/icu/data/) However it looks like that wasn't enough.

Using README.chromium:

There is a readme file inside chromium's icu called README.chromium which has a part about building ICU data:

B. How to build ICU data files


Pre-built data files are generated and checked in with the following steps

1. icu data files for Chrome OS, Linux, Mac and Windows

  a. Make a icu data build directory outside the Chromium source tree
     and cd to that directory (say, $ICUBUILDIR).

  b. Run

    ${CHROME_ICU_TREE_TOP}/source/runConfigureICU Linux --disable-layout --disable-tests


  c. Run make
     'make' will fail  when pkgdata looks for root_subset.res. This
     is expected. See https://unicode-org.atlassian.net/browse/ICU-10570

  d. Run
       ${CHROME_ICU_TREE_TOP}/scripts/make_data_all.sh

     This script takes the following steps:

     i) scripts/trim_data.sh
       The full locale data for Chrome's UI languages and their select variants
       and the bare minimum locale data for other locales will be kept.

     ii) scripts/make_data.sh
       This makes icudt${version}l.dat.

     iii)  scripts/copy_data.sh common
       This copies the ICU data files for non-Android platforms
       (both Little and Big Endian) to the following locations:

       common/icudtl.dat
       common/icudtb.dat

     iv) cast/patch_locale.sh
       On top of trim_data.sh (step d), further cuts the data entries for
       Cast.

     v) Repeat ii) and iii) for cast to get cast/icudtl.dat

     vi) android/patch_locale.sh
       On top of trim_data.sh (step d), further cuts the data entries for
       Android.

     vii) Repeat ii) and iii) for Android to get android/icudtl.dat

     viii) ios/patch_locale.sh
       Further cuts the data size for iOS.

     ix) Repeat ii) and iii) for iOS to get ios/icudtl.dat

     x) Repeat ii) and iii) for Flutter to get flutter/icudtl.dat

     xi) scripts/clean_up_data_source.sh

     This reverts the result of trim_data.sh and patch_locale.sh and
     make the tree ready for committing updated ICU data files for
     non-Android and Android platforms.

  e. Whenever data is updated (e.g timezone update), take step d as long
  as the ICU build directory used in a ~ c is kept.

So I did all that. Still nothing got fixed, same error.

Using Official ICU's Docs:

There are some docs inside the official ICU website about ICU data:
http://userguide.icu-project.org/icudata

It says that there are 3 ways of loading data to ICU

  1. Using Library Linking which is the default mode.
  2. providing a path to the ICU data files (not archived)
  3. providing a path to the ICU data files that are archived (.dat)

So I realized that there are two .dat files that have changed and git is showing them as unstashed files inside /deno/third_party/icu/common I did a quick comparison between these new files that were generated by building the data using the above guide provided by chromium and they were much larger but as I said compiling did not fix the problem.
So I provided the path to the .dat files using #define ICU_PATH_DIR inside putil.h (note that this is not a good choice when we want to compile a single file binary that deno is. because in this way we need to provide the .dat files to the user too and they need to put them in the same PATH that we provide at compile time. the best choice would be library linking here for deno.)
Still this did not fix the problem.
However I did realize that inside the folder that I made earlier (because of what README.chromium said) there are some files with .res ending. (path/to/compilefolder/out/build)
So I gave this path to as ICU_PATH_DIR and now the error was gone!
However there was a new Error:

fish: “./target/debug/deno” terminated by signal SIGSEGV (Address boundary error)

I did a little bit of debugging and I found out that the data was loaded inside ICU, But it was not complete and part of it is still missing (about currencies of the countries I believe)
This is how far I got. I really do not know how I am supposed to build ICU data which is complete and provide them as library links instead of hard coding path.

@ry
Copy link
Member

ry commented Apr 16, 2019

I'm not super keen to add ICU due to its size. But I suppose people need it. :|

@ATheCoder sounds like you're off to a good start. Maybe put up your branch?

@zekth
Copy link
Contributor Author

zekth commented Apr 16, 2019

@ry i totally understand but if we don't add it, maybe a creation of deno_internationalization with polyfills would be a good compromise?

Another alternative would be to have one build with icu and one without. But it means doubling the ci and so on... I'm not really thinking it's a good alternative.

@ATheCoder
Copy link
Contributor

ATheCoder commented Apr 19, 2019

@ry But I didn't manage to get it to work.
I think we need to somehow use the library linking, I tried finding out how NodeJS does it, What they do is that they use a smaller version of ICU, but I don't know how they do it.
More Info:
https://nodejs.org/api/intl.html
https://github.com/nodejs/node/tree/master/tools/icu
Edit: How am I supposed to put up the branch? Should I make a new fork?

@motss
Copy link
Contributor

motss commented Apr 24, 2019

AFAIK, even Node.js does not include full ICU sometimes on certain platform. It'd would be better off adding new flag that allows users to use whichever ICU they want instead of embedding it because of the size concern. An awesome package like full-icu is used in such case.

@flying-sheep
Copy link
Contributor

Another thing: It’s pretty crazy that node doesn’t have an API to set the locale at runtime.

It’s pretty important to be able to do that, e.g. when offering a language switcher in your application or running the tests in a predictable environment.

@hayd
Copy link
Contributor

hayd commented Oct 19, 2019

node have recently made full-icu the default: nodejs/node#19214
(compressed file ~9Mb 😬 but IMO necessary.)

@zekth
Copy link
Contributor Author

zekth commented Oct 19, 2019

Can't agree more with @hayd

@Lonniebiz
Copy link

deno 1.0.0-rc3 | v8 8.4.300 | typescript 3.8.3

It looks like this issue will persist into the Deno 1.0.0 release. I ran this code on 1.0.0-rc3 and the same error remains.

I like Ryan's eye for performance and efficient resource utilization. On one hand, it seems reasonable to me, that people who don't need Intl, ought to benefit from some leanness by not having it included. On the other hand, it is a specified standard that I expected to be included in deno.

Are there any workarounds (other than simply writing code that doesn't use Intl)? For example, can you somehow import Intl support into your deno project?

@kishiguro
Copy link

kishiguro commented May 24, 2020

  • Update to have Windows build instruction (2020/05/26)

I could managed to make ICU to work. Basically I follow the instruction which @ATheCoder provided earlier in this ticket. One change I made was data file to be embedded in the ICU library.
Here is the updated procedure of it.

Compiling Deno with chromium's ICU:

  1. git clone rusty_v8 and deno.
git clone --recursive git@github.com:denoland/rusty_v8.git
git clone --recursive git@github.com:denoland/deno.git
  1. Change deno/core/Cargo.toml to refer local rusty_v8.
diff --git a/core/Cargo.toml b/core/Cargo.toml
index ebd10838..409fb9ef 100644
--- a/core/Cargo.toml
+++ b/core/Cargo.toml
@@ -19,7 +19,7 @@ futures = { version = "0.3.4", features = ["thread-pool", "compat"] }
 lazy_static = "1.4.0"
 libc = "0.2.69"
 log = "0.4.8"
-rusty_v8 = "0.4.2"
+rusty_v8 = { version="0.4.2", path="../../rusty_v8" }
 serde_json = "1.0.52"
 url = "2.1.1"
  1. Change the flag of v8_enable_i18n_support to true in the rusty_v8/.gn file
diff --git a/.gn b/.gn
index b21600a..5c74f75 100644
--- a/.gn
+++ b/.gn
@@ -28,7 +28,7 @@ default_args = {

   # https://cs.chromium.org/chromium/src/docs/ccache_mac.md
   clang_use_chrome_plugins = false
-  v8_enable_i18n_support = false
+  v8_enable_i18n_support = true
   v8_monolithic = false
   v8_use_external_startup_data = false
   v8_use_snapshot = true
  1. Clone chromium's ICU from git clone https://chromium.googlesource.com/chromium/deps/icu to rusty_v8/third_party
$ cd rusty_v8/third_party
$ git clone https://chromium.googlesource.com/chromium/deps/icu.git
  1. Checkout ICU to the version specified in rusty_v8/v8's DEPS file.
$ grep icu rusty_v8/v8/DEPS
'v8/third_party/icu':
    Var('chromium_url') + '/chromium/deps/icu.git' + '@' + 'f2223961702f00a8833874b0560d615a2cc42738',
$ cd rusty_v8/third_party/icu
$ git checkout f2223961702f00a8833874b0560d615a2cc42738
  1. Change ICU build config rusty_v8/third_party/icu/config.gni for data file to be embedded in the library
diff --git a/config.gni b/config.gni
index c64f8348..d42678be 100644
--- a/config.gni
+++ b/config.gni
@@ -5,7 +5,7 @@
 declare_args() {
   # Tells icu to load an external data file rather than rely on the icudata
   # being linked directly into the binary.
-  icu_use_data_file = true
+  icu_use_data_file = false
   # If true, compile icu into a standalone static library. Currently this is
   # only useful on Chrome OS.
   icu_disable_thin_archive = false
  1. Build Deno
$ cd deno
$ V8_FROM_SOURCE=1 cargo build -vv

On Linux, there would be no issue for compiling. On Mac we might need to apply one change to build config file to refer ICU header file location. I'm not expert of the V8 build system, so there would be much better solution for it. Anyway I could build Deno with following change on Mac.
Also on Windows we might need to have changes described in 9.

  1. (Only on Mac) When build fails due to #include <unicode/uversion.h> can't be found.
    Here is a patch against rusty_v8/build/config/mac/BUILD.gn.
    It seems this won't necessary anymore - @kishiguro 2020/11/22
diff --git a/config/mac/BUILD.gn b/config/mac/BUILD.gn
index de8233bba..b6a3778dc 100644
--- a/config/mac/BUILD.gn
+++ b/config/mac/BUILD.gn
@@ -47,6 +47,7 @@ config("compiler") {
   if (export_libcxxabi_from_executables) {
     ldflags += [ "-Wl,-undefined,dynamic_lookup" ]
   }
+  cflags += [ "-I../../../../rusty_v8/third_party/icu/source/common" ]
 }

 # This is included by reference in the //build/config/compiler:runtime_library
  1. (Only on Windows) Remove leading '_' from ICU built in data symbol.

It seems we might need to remove leading '_' from ICU bult in data symbol.
To do that apply below patch to generation script rusty_v8/third_party/icu/scripts/make_data_assembly.py.

diff --git a/scripts/make_data_assembly.py b/scripts/make_data_assembly.py
index 94b07c81..eb2bf72c 100755
--- a/scripts/make_data_assembly.py
+++ b/scripts/make_data_assembly.py
@@ -60,10 +60,10 @@ if options.mac:
                "\t.align 4\n"
                "_icudt%s_dat:\n" %tuple([version_number] * 3))
 elif options.win:
-  output.write(".globl _icudt%s_dat\n"
+  output.write(".globl icudt%s_dat\n"
                "\t.section .rdata\n"
                "\t.balign 16\n"
-               "_icudt%s_dat:\n" % tuple([version_number] * 2))
+               "icudt%s_dat:\n" % tuple([version_number] * 2))
 else:
   output.write(".globl icudt%s_dat\n"
                "\t.section .note.GNU-stack,\"\",%%progbits\n"

Run Deno to try ICU functions.

Once build success, we can try ICU functionality with the new Deno binary.

$ deno/target/debug/deno
Deno 1.0.2
exit using ctrl+d or close()
> new Date().toLocaleString("en-US", {timeZone: "America/New_York"});
5/24/2020, 5:27:10 AM
> const formatjp = new Intl.NumberFormat('ja-JP', { style: 'currency',currency: 'JPY'}).format;
undefined
> formatjp('1280000');
¥1,280,000

@bartlomieju
Copy link
Member

@kishiguro what's the size of resulting binary?

@kishiguro
Copy link

with debug build (no strip of symbol) on Linux, it looks like this. let me compare it with non ICU version.

$ /usr/local/bin ls -l deno
-rwxrwxr-x 2 kunihiro kunihiro 287257448 May 24 17:54 deno

@zekth
Copy link
Contributor Author

zekth commented May 24, 2020

with debug build (no strip of symbol) on Linux, it looks like this. let me compare it with non ICU version.

$ /usr/local/bin ls -l deno
-rwxrwxr-x 2 kunihiro kunihiro 287257448 May 24 17:54 deno

Could you ls -lh ? (to be humanely readable)

@kishiguro
Copy link

kishiguro commented May 24, 2020

Here is summary of binary size. Parenthesis value is non-strip binary size.

OS Non ICU With ICU Increase
Linux 72M(257M) 86M(274M) 14M
Mac 63M(108M) 76M(124M) 13M
Windows 54M 67M 13M

I guess ICU code+data size would be around 13-14M. This result matches to nodejs's full ICU support thread result nodejs/node#19214 (on Mac 35M->49M roughly 14M increase).

@kishiguro
Copy link

Trying to build on Windows. Non ICU version can be built without any issue. But ICU build can't be completed with following error.

$ cd deno
$ cargo build -vv
...
[591/1425] LINK gen-regexp-special-case.exe gen-regexp-special-case.exe.pdb
FAILED: gen-regexp-special-case.exe gen-regexp-special-case.exe.pdb
ninja -t msvc -e environment.x64 -- ..\clang\bin\lld-link.exe /nologo "-libpath:..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\ATLMFC\lib\x64" "-libpath:..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\lib\x64" "-libpath:..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64" "-libpath:..\..\..\..\..\..\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64" /OUT:./gen-regexp-special-case.exe /PDB:./gen-regexp-special-case.exe.pdb @./gen-regexp-special-case.exe.rsp
lld-link: error: undefined symbol: icudt67_dat
>>> referenced by .\..\..\..\..\rusty_v8\third_party\icu\source\common\udata.cpp:698
>>>               obj/third_party/icu\icuuc/udata.obj:(struct UDataMemory * __cdecl openCommonData(char const *, int, enum UErrorCode *))
>>> referenced by .\..\..\..\..\rusty_v8\third_party\icu\source\common\udata.cpp:722
>>>               obj/third_party/icu\icuuc/udata.obj:(struct UDataMemory * __cdecl openCommonData(char const *, int, enum UErrorCode *))
[592/1425] ACTION //v8:generate_bytecode_builtins_list(//build/toolchain/win:win_clang_x64)
[593/1425] CXX obj/v8/src/inspector/inspector/Runtime.obj
ninja: build stopped: subcommand failed.

--- stderr
thread 'main' panicked at '
command did not execute successfully, got: exit code: 1

build script failed, must exit now', C:\Users\kunih\.cargo\registry\src\github.com-1ecc6299db9ec823\cargo_gn-0.0.15\src\lib.rs:203:3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@kishiguro
Copy link

kishiguro commented May 25, 2020

icudt67_dat must be defined as ICU data source. On Mac it is defined in icudtl_dat.o

$ ~/rust/deno/target/debug/gn_out/obj/third_party/icu/icudata master* ls -lh
-rw-r--r--  1 kunihiro  staff    10M May 25 18:58 icudtl_dat.o
$ nm icudtl_dat.o
0000000000000000 S _icudt67_dat

Looks like this is built from deno/target/debug/gn_out/gen/third_party/icu/icudtl_dat.S.

.globl _icudt67_dat
#ifdef U_HIDE_DATA_SYMBOL
        .private_extern _icudt67_dat
#endif
        .data
        .const
        .align 4
_icudt67_dat:

.long 0x27DA0090,0x14,0x020000,0x446E6D43,1,3,0x706F4320,0x67697279,0x28207468,
0x32202943,0x20363130,0x20646E61,0x6574616C,0x55203A72,0x6F63696E,0x202C6564,
0x2E636E49,0x646E6120,0x68746F20,0x2E737265,0x63694C20,0x65736E65,0x74202620,
0x736D7265,0x20666F20,0x3A657375,0x74746820,0x2F2F3A70,0x2E777777,0x63696E75,
0x2E65646F,0x2F67726F

Need to figure out how this is built on Windows...

  • Update 1: it seems at least object file is created on Windows as well. Although it didn't linked properly...
C:\Users\kunih\deno\target\debug\gn_out\obj\third_party\icu\icudata>ls -lh
total 11M
-rwx------+ 1 kunih kunih 11M May 25 14:04 icudtl_dat.obj
  • Update 2: At least ninjya build file is properly made. It points out icudtl_dat.obj. I'm wondering why link failed...

@kishiguro
Copy link

kishiguro commented May 25, 2020

Finally, I managed to make Windows version work as well. I have updated binary image size above table (13M increase on Windows).
The trick is generated cc file's symbol to be without leading '_'. During the build file gn_out\gen\third_party\icu\icudtl_dat.cc will be generated. In my env, the file is located at:

C:\Users\kunih\deno\target\debug\gn_out\gen\third_party\icu\icudtl_dat.cc

I made change to remove leading '_' from the symbol.

  • Update: instead of modifying generated code, I made change to generation script.
diff --git a/scripts/make_data_assembly.py b/scripts/make_data_assembly.py
index 94b07c81..eb2bf72c 100755
--- a/scripts/make_data_assembly.py
+++ b/scripts/make_data_assembly.py
@@ -60,10 +60,10 @@ if options.mac:
                "\t.align 4\n"
                "_icudt%s_dat:\n" %tuple([version_number] * 3))
 elif options.win:
-  output.write(".globl _icudt%s_dat\n"
+  output.write(".globl icudt%s_dat\n"
                "\t.section .rdata\n"
                "\t.balign 16\n"
-               "_icudt%s_dat:\n" % tuple([version_number] * 2))
+               "icudt%s_dat:\n" % tuple([version_number] * 2))
 else:
   output.write(".globl icudt%s_dat\n"
                "\t.section .note.GNU-stack,\"\",%%progbits\n"

I'm not really sure why link success with this change (I know in C/C++ world symbol always has leading '_'). Anyway at least it build and works fine.

C:\Users\kunih\deno\target\debug>deno
Deno 1.0.2
exit using ctrl+d or close()
> new Date().toLocaleString("en-US", {timeZone: "America/New_York"});
5/25/2020, 9:57:20 AM
> const date = new Date(Date.UTC(2018, 5, 26, 7, 0, 0));
undefined
> const options = { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' };
undefined
> console.log("raw:          ", date.toLocaleString());
raw:           2018/6/26 16:00:00
undefined
> console.log("locale en-US: ", date.toLocaleString("en-US"));
locale en-US:  6/26/2018, 4:00:00 PM
undefined
> console.log("locale en-DE: ", date.toLocaleString("de-DE", options));
locale en-DE:  Dienstag, 26. Juni 2018
undefined
> console.log("long output:  ", date.toLocaleString("en-US", options));
long output:   Tuesday, June 26, 2018
undefined
>
> const formatjp = new Intl.NumberFormat('ja-JP',
   { style: 'currency',currency: 'JPY'}).format;
undefined
> formatjp(1230000);
¥1,230,000
>

Now question is are we going forward to have ICU support by default? IMHO, 14M increase for full ICU support will worth it.

@bartlomieju
Copy link
Member

@kishiguro have you checked the sizes of release binaries? They might end up different that debug ones.

@kishiguro
Copy link

kishiguro commented May 25, 2020

@bartlomieju sure, let me check it. There was significant change of the binary size.

OS Non ICU With ICU Increase
Linux 36M 48M 12M
Mac 32M 44M 12M
Windows 35M 47M 12M

with the release build, on all platform increased binary size is around 12M.

@michael-spengler
Copy link
Contributor

michael-spengler commented Aug 17, 2020

On the one hand it seems convenient to have statements like

new Date().toLocaleString("en-US", {timeZone: "America/New_York"})

behaving in the expected way. On the other hand I wonder whether it would be a worthwhile alternative to provide the corresponding features via a third party module - saving binary size of around 12M ... if I got things correctly.

I created a third party module which serves my private little fun requirements: https://deno.land/x/time in this context as an alternative.

@0kku
Copy link

0kku commented Oct 15, 2020

An external library wouldn't work on regexes. I surely hope people aren't expected to recompile all their regexes to be Deno-compatible... None of the Unicode category matches work in Deno, and an external import won't fix regex literals.

@0kku
Copy link

0kku commented Oct 15, 2020

So I would ask: why is an entire Web Browser 31 MB, but Deno
with ICU is 47 MB

ICU has gotten a lot more features since FF4.

@Lonniebiz
Copy link

I reported this bug on Jan 31, 2019 (see #1636). That's approaching "2 years ago".

Nodejs supports this standard and so does every major web browser.

Does Deno not intend to support internationalization?

I'm just curious: what's the main reason for delay on this? Is it due to "apprehension over whether or not to support it", or (more so) due to the "difficultly of supporting it"?

@kitsonk kitsonk added the feat new feature (which has been agreed to/accepted) label Oct 15, 2020
@kitsonk
Copy link
Contributor

kitsonk commented Oct 15, 2020

I'm just curious: what's the main reason for delay on this? Is it due to "apprehension over whether or not to support it", or (more so) due to the "difficultly of supporting it"?

It is two fold. Priority and finding the right balance of the functional needs with the "cost" of adding ICU. If we add all of the ICU that will dramatically increase the size of the executable, for something that not everyone needs or uses. If we put just en-us, that is more reasonable, but then do we need to have a mechanism for loading other regions? Probably, then that gets into the more complex category. Because it keeps getting bumped into the hard category, and there have been lots of other things to deal with has made are the root causes... We all agree we need it though.

@Lonniebiz
Copy link

Lonniebiz commented Oct 16, 2020

I thought @kishiguro had already gotten full ICU support working on Linux, Mac, and Windows from reading these comments above:

Here's what I think would be really cool: What if you ported Internationalization to web assembly and wrapped that with an ES6 module?

Then, if someone needs Internationalization, they are one ES6 include away from having it.

This is probably way easier said than done, but if accomplished it would address the performance priorities that are causing reluctance and apprehension on this issue.

@kitsonk
Copy link
Contributor

kitsonk commented Oct 16, 2020

I thought @kishiguro had already gotten full ICU support working on Linux, Mac, and Windows from reading these comments above

Yes, exactly... full ICU support is a 25% increase in executable size. 🤯 That is huge. Which leads to the "how do we only do something like en-us and if so, do we allow people to dynamically load other regions or not" problem, which gets into the too difficult category.

Here's what I think would be really cool: What if you ported Internationalization to web assembly and wrapped that with an ES6 module?

It doesn't work that way.

@kitsonk
Copy link
Contributor

kitsonk commented Oct 16, 2020

The core team discussed this today and agreed it is something we need to get into Deno. The "right" way to add it is to add ICU support to rusty_v8, the simple tracking issue is here: denoland/rusty_v8#501.

Once it is added to rusty_v8 it can be integrated into the CLI.

@flying-sheep
Copy link
Contributor

If we care about the detractors we could use cargo-bloat to create a piechart somewhere in the docs that shows a breakdown of deno’s executable size. Maybe it would be good having the argument readily available that “those 25% of its size is so you have ICU support as specified by the standard”

@glowingblue-dev
Copy link

glowingblue-dev commented Jan 5, 2021

no idea if that's a potential path forward, but how about two deno builds, basically one with ICU and one without for apps that don't need it and want to save the bloat?

@kitsonk
Copy link
Contributor

kitsonk commented Jan 5, 2021

We are working on a solution for Deno 1.7.0.

@zbraniecki
Copy link

Hi. I'm one of the authors of ICU4X which is a Rust implementation of ICU. We're quite young (with just 0.1 released), but we're working on 0.2 now which we hope to provide some basic ECMA-402 compatible functionality (DateTimeFormat, PlrualRules, Locale etc.)

We also have ecma_402 traits and some ICU4C wrappers in Rust that are used by the Fucshia team for now.

Would you consider cooperating with us instead of writing your own bindings?

Link: https://github.com/unicode-org/icu4x and https://crates.io/crates/rust_icu

@kitsonk kitsonk added this to the 1.8.0 milestone Jan 21, 2021
@bartlomieju
Copy link
Member

ICU support has landed in #9466 and will be released in 1.8.0 on March, 2nd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli related to cli/ dir feat new feature (which has been agreed to/accepted) web related to Web APIs
Projects
None yet
Development

No branches or pull requests

15 participants