Bundling with Webpack doesn't work well

[jquense]

congrats on 1.0! been waiting a long time to use the shiney new globalize :)

I have been running into issues using Globalize with webpack ( browserify may suffer similarly).

ERROR in ./~/globalize/dist/globalize/number.js
Module not found: Error: Cannot resolve module 'cldr' in \node_modules\globalize\dist\globalize

Investigation shows that this is due to the AMD check running first in the UMD wrapper for the files, since the package has been installed from npm there is no cldr package for webpack to find. there is a cldrjs however and if I tell webpack to ignore amd style modules for globalize it works just fine.

The problem is that as a library author using Globalize and publishing to npm I can't ask consumers of my module to add a special exemption to there build process in order to get my module to load. I am not sure what the best way to "fix" this is other then building a commonjs (or amd) only version of globalize that gets published to npm, instead of the general /dist build that works for both bower and npm

[rxaviers]

Hello, thanks for your interest and for submitting this issue.

I haven't looked deep into it yet. But, as far as I understood, webpack parses the file, finds every occurrence of require (for cjs) or define (for AMD), figures out the module names and tries to crawl them all. Is that correct?

My first question, why doesn't it consider the cjs information rather than the AMD one from the UMD?

[rxaviers]

Some other curiosity-questions... Does wekpack try to include the modules below?

a)

// A:
if ( false ) {
  require( "this-module-should-never-be-loaded" );
}

// B:
// require( "commented-out-module" );

[jquense]

Thanks for the quick response!

I haven't looked deep into it yet. But, as far as I understood, webpack parses the file, finds every occurrence of require (for cjs) or define (for AMD), figures out the module names and tries to crawl them all. Is that correct?

exactly, and then concats it all together, its similar to the requirejs pre-processor step, except that it supports all sorts of module/file types and is plug-able for fancier things.

why doesn't it consider the cjs information rather than the AMD one from the UMD?

It supports amd, so it doesn't mind loading it, however, the npm package doesn't install a dependency called cldr only one called cldrjs, so you get an error because it can't find it. If the question is "why doesn't it then try the commonjs branch of the UMD wrapper" I think its just not that smart.

Does webpack try to include the modules below?

both of those approaches work in webpack. It is smart enough to not try in the case of if (false) and definitely ignores commented code. However this will fail:

var no = false
if ( no ) {
  require( "this-module-should-never-be-loaded" ); //will try and load it
}

[rxaviers]

cc @jzaefferer @scottgonzalez for input.

[scottgonzalez]

Have you talked to the webpack team about this? If Globalize is working properly on its own for CJS and AMD environments, it sounds like webpack has a bug.

[jquense]

hey @scottgonzalez thanks for helping out! Its definately not a webpack bug. The underlying issue is that Globalize defines a dependancy that doesn't exist in the npm package. The webpack "environment" is unique because its one of the few places that both module types are valid , so the UMD wrapper never fails on any of its checks.

The reason it works in node is that the check for define fails so it drops down to the check for module and module.exports. In webpack (and also browserify if amdify is being used) the first check for define succeeds, It then tries to load the amd module, at which point it fails because it is missing a dependency cldr.

The problem is that the cldr dependency is called two different things: cldr and cldrjs in the npm package there is no such thing as that first one.

The brittle fix is just to move the check for cjs before the amd check.

[rxaviers]

@jquense, you are saying that webpack is capable of interpreting both CJS and AMD modules simultaneously and it works. On AMD, cldr is bind to whatever you define on AMD config.paths, it doesn't mean one should find a cldr module on npm. Which config.paths are you using?

[jquense]

I should probably demonstrate with code. If you npm install globalize you get two dependencies installed (in the globalize folder) with the following structure installed:

• dist
• node_modules
  • cldr-data
  • cldrjs

and here is the UMD wrapper globalize defines (this is around: dist/globalize)

       if ( typeof define === "function" && define.amd ) {
        define(["cldr","cldr/event"], factory );
    } else if ( typeof exports === "object" ) {
        module.exports = factory( require( "cldrjs" ) );
    } else {
          // global one omitted
    }

By default Webpack understands both module formats so as it parses this file it hits: define(["cldr","cldr/event"], factory ); first (it won't run the other branches if it succeeds) and so tries to find both cldr and cldr/event. Presumably if I had installed Globalize via bower that dependency would be sitting in my bower_components (I don't ever use AMD or bower so I am not sure on that). However, since I used npm the only place to check is node_modules and it finds no module by that name in node_modules and fails.

if it had run: module.exports = factory( require( "cldrjs" ) ); first it would have found cldrjs in node_modules and bundled it successfully

[rxaviers]

And I'm saying that on AMD there's no hard definition for module names. Let me demonstrate with code for you as well https://github.com/jquery/globalize/blob/master/test/config.js#L4 (on AMD you must tell where the modules come from or it's expected there's a file on baseDir with such name).

Anyway, can you make a test please? If you rename cldr occurences to cldrjs in your localnode_modules/globalize/dist/* files, does it work? I think you'll get a failure on "cldr/event".

[jquense]

And I'm saying that on AMD there's no hard definition for module names

Gotcha, sorry I don't use AMD modules, forgive my ignorance :). Yeah if I change the name it fails on cldr/event.

[rxaviers]

We need to understand how to pass an AMD config to webpack or have webpack to simply ignore the AMD definitions.

[jquense]

So that is easy enough to do as the person webpacking the files. Unfortunately I don't think there is anything module authors can do to define configurations for potential consumers.

How does it work with requirejs? If I release a library that depends on globalize can I set of the paths so someone installing my module doesn't have to (i.e. doesn't need to worry about wiring up my dependencies) or would they have to set it all up themselves as well?

Some context. I'm coming from the React.js community which mostly uses cjs, npm, and webpack to publish and distribute components (both for server/browser). The advantage being consumers of my components will just get all my dependencies installed and webpack/browserify will package them up without a consumer needing to have any knowledge of my dependencies and I don't have to create a bundle to publish I can just keep my package all in modules.

[jquense]

on second thought tho if you are going to configure the amd stuff anyway then my original solution should work? Reordering the UMD to:

if ( typeof exports === "object" ) {
  module.exports = factory( require( "cldrjs" ) );
} else if ( typeof define === "function" && define.amd ) {
  define(["cldr","cldr/event"], factory );
} else {
  // global one omitted
}

[rxaviers]

How does it work with requirejs? If I release a library that depends on globalize can I set of the paths so someone installing my module doesn't have to (i.e. doesn't need to worry about wiring up my dependencies) or would they have to set it all up themselves as well?

Using AMD, they would need to set it all up themselves AFAIK.

Reordering the UMD to:

Does reordering work for you locally please?

[jquense]

Does reordering work for you locally please?

Can confirm that it Works on My Machine™ if I reorder the UMD wrapper