Codecov Report

Merging #855 into dev will not change coverage by %.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##               dev      #855   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          158       160    +2     
  Lines         1195      1205   +10     
  Branches       246       248    +2     
=========================================
+ Hits          1195      1205   +10     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd24034...5b98c98. Read the comment docs.

Seems not quite necessary?

Why not just parse the locale string before passing into dayjs.locale?

Well, we support A LOT of locales (or at least try to), so it wouldn't really be reasonable to have to check each and every locale for what should be used in it's stead. We currently default to the base language's locale if the specific country's locale is not supported but I imagine for a lot of locales this is not correct. I figured it'd be a good thing for dayjs to support as many locales as possible out of the box, especially this way, as it is rather lightweight.
A lot of the currently supported english locales I noticed are almost exactly the same, perhaps a similar approach could be adopted with those to make them more lightweight?

Can you provide a list on Wikipedia or some alike that has these two locale strings, please?

Besides, please avoided using es6 syntax. Cause it will enlarge the final bundle size.

Not entirely sure what you mean but I looked here at these links when confirming what was required.
http://www.localeplanet.com/icu/en-IN/index.html & http://www.localeplanet.com/icu/en-TT/index.html
So you'd rather have the locales defined in full to reduce bundle size?

So you'd rather have the locales defined in full to reduce bundle size?

Yes, please.

And any difference between en-IN and en-in, or which one we should choose?

I've dropped the ES6 syntax, although I saw no difference in build size locally.

As for en-IN vs. en-in, the capitalised country code is the standard as far as I'm aware. But the locales in dayjs use lowercase country codes (except en-SG, not sure why). Perhaps it would be good to make things consistent?

Thanks, let's get this merged first. 😬

thanks

🎉 This PR is included in version 1.8.24 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀