Breaking down the Intl.js source code

[andyearnshaw]

I've been experimenting making the source code a little more modular to try and achieve the following results:

• Better organisation of source code
• Easier to extend with missing or newer spec features and proposals
• No need to rebuild Intl.complete.js every time we need to run the tests
• Configurable build process (e.g. build without DateTimeFormat)

I figured this was necessary when I started looking at the timezone stuff, so I've been doing bits here and there when I could. The modularsrc branch is my most recent effort, with the polyfill being fully functional in Node.js but with no current build process. I've probably made it a little more complicated than I originally hoped for, because of how Node's modules work. There are some "circular" requires (e.g. src/intl.js requires src/locale.js which requires src/intl.js to get the Intl object) but I think I can eliminate those.

I was looking into using UglifyJS2's AST tree transformer to build all the files together with optional minification and source maps. Browserify doesn't seem to be appropriate and adds a bit of cruft (including a require() shim).

I'd like to hear some thoughts and feelings on this before proceeding, because it's quite a large change and I may not have taken the best approach so far.

/cc @caridy, @ericf, @drewfish

[caridy]

@andyearnshaw this is definitely an area where we can help since we have the exact same issues in many of our projects. At this point, we are working on a bundling process that can provide:

• easy way to add new dependencies (as modules)
• easy way to support circular references (which often facilitate breaking things down into smaller pieces)
• easy way to produce a bundle (without having to worry about the order of the modules)
• easy way to add additionally logic into the bundle to expose things into a namespace, etc.

As today, we plan to support this thru a Grunt task that will manage ES6 modules into ES5/ES3 modules using System.register(), and having a microloader (very dummy loader to resolve dependencies and imports/exports). We should be able to share more on this in the next few days/weeks (we are at the end of the quarter, you know what I mean).

[andyearnshaw]

@caridy: sounds great. I'm looking forward to being able to move forward with this, it's been haunting me for a long time!

[caridy]

@andyearnshaw we have all the pieces together now, I will submit a PR in the next couple of days with the details to split the library in pieces.

[andyearnshaw]

Great news, Caridy, looking forward to it.

On Fri, Jul 18, 2014 at 3:00 PM, Caridy Patino notifications@github.com
wrote:

@andyearnshaw https://github.com/andyearnshaw we have all the pieces
together now, I will submit a PR in the next couple of days with the
details to split the library in pieces.

—
Reply to this email directly or view it on GitHub
#67 (comment).

[andyearnshaw]

Any update on this, @caridy?

[caridy]

I have a branch but I didn't get enough time to finish it up. Will try to get some time in the next few days.

[andyearnshaw]

Awesome, thanks again. 😄

[chicoxyzzy]

👍

[caridy]

This is done, merged into master, and will get consolidated into 1.0.0-rc-1 in PR #85