Have only a single bundle [ 2.0 / Breaking change]

[onigoetz]

I don't have any numbers to back this up, but I feel that there is a lot of code to account for the fact that some Globalize modules could be loaded or not when using its features.

Wouldn't it be smaller to consolidate in a single bundle and remove the all the existence checks ? and also remove the error generators if a plugin isn't included.

Do you have stats if a lot of people use only a single module or everything at the same time ?

[rxaviers]

It's important to make consumption modular. As a use case, on PayPal different products need different i18n features and they only consume what they need.

The existing build process is a bit tedious and I believe that migrating over to ES modules / rollup / and lerna (https://github.com/globalizejs/globalize/issues/467#issuecomment-217679826) will improve the development experience there.

[onigoetz]

Thanks for your answer.

I just have a doubt about Lerna, as lerna creates multiple packages. I'm not sure in what you direction you plan to go :

• everything in one package and you either include import Globalize from "globalize" or import Globalize from "globalize/core"; import "globalize/currency"
• Multiple packages an you would still have import Globalize from "globalize" and import Globalize from "globalize-core"; import "globalize-currency"

Two things to keep in mind though :

• The first solution has the downside that globalize/currency refers to a file, and thus npm can't automatically decide through the main and browser fields in package.json which file to load. So you'll have to choose between commonjs and es6 imports
• The downside of the second option is that if you have multiple dependencies, the user has to make sure that all dependencies are up-to-date at the same time.

The question will also be : how do they choose between the normal and the runtime build ?

Both solutions are fine, it's just a matter of which tradeoff you're willing to accept.

[rxaviers]

Excellent questions. I am leaned towards using lerna and have an exclusive package for each feature like your (b) example, i.e., globalize-core, globalize-date, etc. Good question about runtime, I think that we can also go with one package for each runtime feature. It's so many packages, but managing them all is pretty easy with lerna.

the user has to make sure that all dependencies are up-to-date at the same time.

True, but lerna also helps with the inter-dependencies. When we do a version bump, it sets them accordingly between dependencies.