Separate distribution files for commonJS module?

[rxaviers]

This topic was originally raised at #441 (comment) by @jquense.

The scope and details of this change needs clarification. But, it's about decoupling CJS support from the UMD files. So, in the end we'll have two separate set of files: one for AMD/Globals and another one for CJS. Details...

What are the pros and cons of building separate distribution files for commonJS module?

Pros:

• Allow webpack (and potentially browserify) to work without additional configuration.
• ...

Cons:

• Additional testing time (due to one more set of files to run functional tests against).
• ...

[jquense]

I admit I don't quite grok how the function tests work now I assume requirejs is actually pulling in the dist files?

I think in general a change like this increases build complexity, which isn't great, but I think reduces overall complexity, since you aren't worrying about npm/bower and browserify/webpack/rjs ecosystem overlap causing odd bugs.

It certainly makes the whole process a lot more straightforward for build tools like webpack/browserify, and I would think newer tools like jspm as well.

[jzaefferer]

Could be use ES6 imports for source files, then compile that to whatever format we need? Hopefully we only need to compile it do AMD/Globals for the browser, while other users can just use the tool of their choice to include the source files, instead of having to rely on our dist output.

[rxaviers]

@jzaefferer, perhaps in the longer term. The simpler question for this issue is: (a) UMD for CJS/AMD/Global or (b) separate builds? Does the benefits of (b) outweighs its potential cons?

[rxaviers]

@jquense it's not a direct answer to your question. But, considering #481 sufficiently fixes #441, it alleviates the urgency of this question and instead we should ignore this and focus on the long term solution of using ES6 for our sources.

What do you think? Is there anything on #481 that wouldn't work for you?

[jquense]

I think #481 is excellent and offers a really robust example of how to build an app on Globalize. I don't think it addresses my initial concern that Globalize is hard to depend on if you are a library an not an app. Even following an excellent example and starter is a lot more work than not having to do anything at all.

For instance, using Moment as a date manipulation library just works calendar and datepicker modules, there is no Setup and installing from npm just works. It only starts to get a bit annoying when you want to include a bunch of cultures (same of Globalize)

[sompylasar]

It only starts to get a bit annoying when you want to include a bunch of cultures (same of Globalize)

@jquense @rxaviers Yes, not being able to load some of the locales, not all of them, is an important issue that should be considered while doing #481. Moment hasn't solved it yet and they have a TODO comment for this. Globalize should allow to bundle only the data that is needed, and be able to load additional data upon requirement.

[jquense]

Globalize, in my experience actually makes this easier becuase it doesn't try to load any cultures itself (like Moment) so you can just require whatever json you want. That being said that is a bit of a workaround to avoiding using cldr.load()

[rxaviers]

I think #481 is excellent and offers a really robust example of how to build an app on Globalize. I don't think it addresses my initial concern that Globalize is hard to depend on if you are a library an not an app

@jquense I understand your concern. The #481 example solves it for the end user who is building the final application. But, what about libraries?

Libraries can depend on Globalize and assume their users will figure out how to use Globalize (e.g., #481 example). Obviously, libraries don't want pre-requisites and I fully comprehend that. Therefore, I have a suggestion below.

For background purposes, previous Globalize version (and some other libraries) allows installing from npm just works, which is exciting and fine for the very first second. But, it's not a durable relationship. Because, it makes maintenance (what happens on outdated CLDR?) and optimizations (how to tune the speed and size of your final bundles?) virtually impossible.

I strongly believe Globalize 1.x has achieved a nice balance between easy ramp up and high flexibility (that allows for easy maintenance and crazy optimizations).

Having said that, I believe a Library can depend on Globalize and still provide a installing from npm just works sort of thing by compiling the Globalize formatters that your Library use yourself in advance for a certain language (e.g., English) and serve your Library with that piece easily available for your users.

What do you think? Just let me know on any questions.

[jquense]

But, it's not a durable relationship. Because, it makes maintenance (what happens on outdated CLDR?) and optimizations (how to tune the speed and size of your final bundles?) virtually impossible

I agree with you here, I don't think its super feasible for a user to not be aware of globalize at all since they are going to have to provide and manage locale info among a bunch of other things. I think its perfectly fine in terms user expectations. however, I think a library failing to compile at all via a cryptic error, from a dependency two levels down is a whole different sort of thing entirely.

Perhaps I am misunderstanding how compiling formatters works, but It (I would be happy to be wrong about this!) doesn't seem like it addresses the issue that globalize is not usable as module in frontend bundling systems that aren't requireJS, without compiler flags.

I am more than happy to help my users learn how to use globalize in their apps, but I don't think I should have to help them understand how to build it, especially since the fix (and I understand you have concerns here) would be swapping two lines of code in the module definition.

I mean Ideally I think I would like to just optionally embed (similar to compiling formatters?) the bare minimum cdlr data, and the code to format for a default culture/locale, and point the use to here for providing support for a larger range of locales, while still providing modules to my users.

complaining aside thanks again for all the work, attention ya'll are putting into this. There is not enough good I18n resources in javascript at the moment, and Globalize is really a shining star in that space.

[rxaviers]

Perhaps I am misunderstanding how compiling formatters works, but It (I would be happy to be wrong about this!) doesn't seem like it addresses the issue that globalize is not usable as module in frontend bundling systems that aren't requireJS, without compiler flags.

Globalize has no ties with requireJS for the user perspective.

I mean Ideally I think I would like to just optionally embed (similar to compiling formatters?) the bare minimum cdlr data, and the code to format for a default culture/locale

This is possible as I have mentioned in my previous comment.

@jquense, do you want to chat, I can walk you through my suggestion. If you are comfortable with that, then we can work on making it public for other library maintainers. I'm on IRC (http://irc.jquery.org/) or email (http://rafael.xavier.blog.br/contact/).

PS:

however, I think a library failing to compile at all via a cryptic error, from a dependency two levels down is a whole different sort of thing entirely.

Please, if this applies could you provide more details? Thanks