fixes #5

[EXC-BAD-ACCESS]

this modification only works only for the developmentLocale, but could be expanded to work for other files or even changes to the cldr data (but i don't think either make sense...so).

requires your webpack configuration to specify the json-loader for json files:

module: {
  loaders: {
    "json": "json-loader"
  }
}

[rxaviers]

Let's remove the trailing space here and double space on = path.resolve.

[rxaviers]

Very cool, thanks.

[rxaviers]

Also, please make sure to sign-off your commit messages:
https://github.com/rxaviers/globalize-webpack-plugin/blob/master/DCO.md

[rxaviers]

What happens if no json-loader is specified? It fails I guess.

[EXC-BAD-ACCESS]

if you have no loader specified whatsoever then webpack will fail to create the bundles and print a message like:

Module parse failed:
You may need an appropriate loader to handle this file type.

if you have some other loader specified for json, then it really depends on the loader behavior. for example for the raw-loader webpack will build the bundles, but when you view a page in your browser that contains a require("globalize") you'll have an error in the console with a message from globalize (i assume) about not being able to parse the provided input and a giant dump of said input.

[EXC-BAD-ACCESS]

Actually there's an issue with my solution above. At some point during my testing i must have placed an actual require("/path/en.json") in my source file which allowed the hot update to take place. without such a require the solution i submitted will only show the changed text on a browser refresh (which is better than a full bundle rebuild, but not ideal or what i intended).

in order to do the hot update correctly we need to perform an addDependency (similar to what's being done at line 56) to the file stored in variable this.messagesPath in my changes. But i haven't been able to figure out how to do that in a plugin (in a loader you could just add a new SourceNode with the content).

So if someone knows how to perform addDependency correctly i'll happily update this so the functionality is complete.

[rxaviers]

Please, give me some moment to review your change (finding free time). Thank you @AppSorcery.

[rxaviers]

I have reviewed your code and something that occurred to me so far is: The end goal of this change is to allow using the built JS files in node according to your example, but I believe we could make the API a bit more clear. I mean, the change is about managing the compiled i18n data in chunks, not strictly about node vs web. Can we make it so that user actually has control over which chunks the i18n compiled data should go to? I don't have a suggestion now, but user should be empowered to say that i18n compiled data should go in its own separate chunks (default), or in the app chunk, or something else.

The interesting thing is that when i18n compiled data is chosen to go in the app chunk, the end result is actually an array of apps (one for each supported locale).

What do you think? Does it make sense to you?

[EXC-BAD-ACCESS]

are you familiar with i18n-webpack-plugin? this is actually what i was using before moving to globalize-webpack-plugin. it's only capable of doing static i18n replacements, but if you look at the example you can see that it is actually used the way (i think) you are refering to. you pass in a single language to the plugin and it builds an entire app with that one language. to do multiple languages, you just take advantage of webpack's "parallel build" capability -- each build being a different language (again demonstrated in the example).