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

Prebuilt packages are quite large in file size #124

Closed
jkillian opened this issue Jun 3, 2019 · 2 comments
Closed

Prebuilt packages are quite large in file size #124

jkillian opened this issue Jun 3, 2019 · 2 comments

Comments

@jkillian
Copy link

jkillian commented Jun 3, 2019

First off, js-joda is great! It makes me actually happy when working with dates/times in TypeScript. So thanks for the work!

However, I recently noticed that our @js-joda/locale_en-us package we're using is quite large. It's one module, as of version 2.0.1, is 302KB which unfortunately bloats our bundle quite a lot. (Of course this filesize will get smaller when uglified and gzipped, but it still adds up to be quite a lot)

In our use case, all we want to be able to do is parse/output a few simple things like month abbreviations and 'am'/'pm'.

I admit I don't fully understand how these packages are built or what's in them. Do you have any recommendations for reducing bundle size in this case? Thanks!

@phueper
Copy link
Member

phueper commented Jun 4, 2019

Hi @jkillian ,

thanks for using js-joda and reporting the issue.

The problem is that for the js-joda-locale package we need to implement parsing and formatting not only for month abbreviations but for all available patterns. We depend on data from cldr that provide some packaging of available localisation strings. There are strings in these packages that we do not need but the packages are as they are.

So i'm afraid at the moment i don't know how to help you reduce the bundle size ... we could think about providing something like "core" packages that only contain some localisation functionality in the future but that is not on the roadmap currently :/

I'll close the issue because of this, feel free to reopen/ comment if you feel there is some way to address this.

Regards, Pattrick

@phueper phueper closed this as completed Jun 4, 2019
@jkillian
Copy link
Author

jkillian commented Jun 5, 2019

Thanks for the response @phueper! Just a couple notes below I wrote up when I was looking at things:

I was first curious about is how much of each locale is actual logic related to parsing and how much is data. When looking at node_modules/@js-joda/locale_en-us/dist/index.js, it's about 300KB, about half of that, 150KB, is data and the other half is logic/code.

As a (somewhat unfair comparison, but a comparison nonetheless), the data for a moment locale appears to be about 4KB.

In the js-joda locale, it looks like the biggest consumers of space are:

cldr-data/supplemental/metaZones.json: 72KB
cldr-data/supplemental/likelySubtags.json: 38KB
cldr-data/main/en/timeZoneNames.json: 32 KB

@phueper I'm curious how this data overlaps with js-joda-timezone? Is there anyway to eliminate the timezone data from the locales packages and instead rely on the timezone data from js-joda-timezone? This could be significant space savings for users.

Another question I have is what the use of cldr-data/supplemental/likelySubtags.json is? Eliminating this would also be significant space savings.

And then these are the remaining data files:

cldr-data/supplemental/weekData.json: 4KB . (so not too bad, but seems to contain data for all locales)
cldr-data/main/en/ca-gregorian.json: 7KB (seems like most of this data is relevant)
cldr-data/availableLocales.json: 3KB (seems like it contains all locales, but this is relatively small so not too bad)

Any thoughts on the above comments? I'm mostly just trying to get a grasp here of what it causing the size bloat and on what data is truly necessary vs. what is extraneous. It seems like time timezone data here is what's the biggest offender.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants