Provide a lightweight version of twitter-cldr-js library

[KL-7]

As we keep adding more advanced features to twitter-cldr-js library (rule-based number formatting, Unicode regexes, etc.) the size of the library is rapidly growing, because some of these features are bundled with rather big chunks of CLDR data. That forces people that don't need these new features either stick with older versions of the library (that lack certain important bug fixes) or accept that twitter-cldr-js will significantly increase the size of the JS bundle that they have to serve to the client.

In fact, a lot of the projects that use the library (both internally and, I imagine, externally) rely only on a fairly small subset of "core" features like dates/numbers/currencies formatting, pluralization, lists formatting, and others that don't require that much data and can be bundled separately in a much smaller package.

We can either define this "core" set of features and publish them to NPM as a separate package (twitter_cldr_light?) or make it easier to compile an arbitrary subset of features (accounting for internal dependencies) as a separate bundle, so that people can build their own twitter-cldr-js and add it directly to their project as a source code dependency.

[camertron]

Being able to create your own bundle of features would be really cool. I've thought about doing this for the Ruby version as well, although it's not as critical there. We could create individual libraries for each feature similar to how rspec does things. We'd have something twitter-cldr-js-core and twitter-cldr-js-segmentation, twitter-cldr-js-datetimes, etc.

[KL-7]

I'd probably start by adding a configuration option to twitter_cldr:js:compile rake task that would allow you to choose modules that you need and compile them in a separate directory. That should be very simple and will only require a slightly better organization of renderers in the Compiler class to account for dependencies between features.

Having multiple libraries is definitely an option, but I feel like it might be a pain managing possible dependencies between them or releasing them all at once when a common part is updated.

Another option is introducing better modularization within the library itself (probably after Arnav is done with his work on data/logic separation). Instead of compiling one gigantic JS file per locale, we can generate a bunch of files. The separation might be very similar to what you're suggesting, but within one library. E.g., we can have fr/core.js, fr/segmentation.js, fr/datetimes.js, etc, so that people can choose just the files they need when they bundle them together with the rest of their JS code. I'm not sure if it's as easy in bower/npm to require and bundle specific files as it is in the assets pipeline in Rails, but I think that would be a decent compromise between one library with monolithic JS resource per locale and a bunch of related JS libraries.

FYI, I backported a few bug fixes to v2.3.2 and released a new npm package from this commit.

[mikemorris]

+1

I'm investigating using this library for mapbox/DEPRECATED-mapbox-gl#4 and need ONLY the bidirectional logic, but not restricted to a single locale. From a quick glance, it looks like the bidirectional logic that ends up in each locale-specific file is identical. I'd be happy to help break this out into a standalone module, ideally ported back to plain JavaScript to make performance enhancements like #68 easier to implement.

[mikemorris]

Drafted up a sketch of what breaking out the Bidi and Utilities modules could look like in mapbox/mapbox-gl-js#1841 if y'all are interested.

[camertron]

Hey @mikemorris glad to see someone getting some mileage out of the bidi stuff. I don't think there's much we can do to help at the moment, since we haven't yet divided the library up into different modules. I also read over the mapbox PR you linked to, looks like you've managed to get the size down by only including one copy of the bidi logic. You're correct in saying the logic is the same for all locales - the bidi algorithm is not locale-specific.

@KL-7 @radzinzki Can someone refresh my memory regarding the status of the data/logic separation? Is modularization/customization something we could reasonably tackle right now?

[arnavk]

The data/logic separation is good to go (I just need to update docs, something I'm planning to do this weekend). Once that is done I can start working on a draft/proposal of modularization.