{"action":"created","issue":{"url":"https://api.github.com/repos/jquery/globalize/issues/441","labels_url":"https://api.github.com/repos/jquery/globalize/issues/441/labels{/name}","comments_url":"https://api.github.com/repos/jquery/globalize/issues/441/comments","events_url":"https://api.github.com/repos/jquery/globalize/issues/441/events","html_url":"https://github.com/jquery/globalize/issues/441","id":70785802,"number":441,"title":"Bundling with Webpack doesn't work well","user":{"login":"jquense","id":339286,"avatar_url":"https://avatars.githubusercontent.com/u/339286?v=3","gravatar_id":"","url":"https://api.github.com/users/jquense","html_url":"https://github.com/jquense","followers_url":"https://api.github.com/users/jquense/followers","following_url":"https://api.github.com/users/jquense/following{/other_user}","gists_url":"https://api.github.com/users/jquense/gists{/gist_id}","starred_url":"https://api.github.com/users/jquense/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jquense/subscriptions","organizations_url":"https://api.github.com/users/jquense/orgs","repos_url":"https://api.github.com/users/jquense/repos","events_url":"https://api.github.com/users/jquense/events{/privacy}","received_events_url":"https://api.github.com/users/jquense/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":20,"created_at":"2015-04-24T20:26:40Z","updated_at":"2015-05-17T21:14:11Z","closed_at":null,"body":"congrats on `1.0`! been waiting a long time to use the shiney new globalize :)\r\n\r\nI have been running into issues using Globalize with webpack ( browserify may suffer similarly).\r\n\r\n```js\r\nERROR in ./~/globalize/dist/globalize/number.js\r\nModule not found: Error: Cannot resolve module 'cldr' in \\node_modules\\globalize\\dist\\globalize\r\n```\r\n\r\nInvestigation 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.\r\n\r\nThe 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"},"comment":{"url":"https://api.github.com/repos/jquery/globalize/issues/comments/102859098","html_url":"https://github.com/jquery/globalize/issues/441#issuecomment-102859098","issue_url":"https://api.github.com/repos/jquery/globalize/issues/441","id":102859098,"user":{"login":"jquense","id":339286,"avatar_url":"https://avatars.githubusercontent.com/u/339286?v=3","gravatar_id":"","url":"https://api.github.com/users/jquense","html_url":"https://github.com/jquense","followers_url":"https://api.github.com/users/jquense/followers","following_url":"https://api.github.com/users/jquense/following{/other_user}","gists_url":"https://api.github.com/users/jquense/gists{/gist_id}","starred_url":"https://api.github.com/users/jquense/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jquense/subscriptions","organizations_url":"https://api.github.com/users/jquense/orgs","repos_url":"https://api.github.com/users/jquense/repos","events_url":"https://api.github.com/users/jquense/events{/privacy}","received_events_url":"https://api.github.com/users/jquense/received_events","type":"User","site_admin":false},"created_at":"2015-05-17T21:14:11Z","updated_at":"2015-05-17T21:14:11Z","body":"@JeremyRylan A less brittle solution you can try is to add this loader to your webpack config\r\n\r\n```js\r\n{ test: /globalize/, loader: 'imports?define=>false' }\r\n```\r\n\r\nWhich will tell Webpack to ignore AMD imports for modules that match globalize packages (untested). \r\n\r\nAs I say in above posts, this is an ok solution for app developers, but not feasible for building libraries that depend on globalize. If you are looking for a real life use case you can check out https://github.com/jquense/react-widgets which is a component library I maintain that depends on globalize for date and number pickers, but I am stuck with using pre `1.0.0` until I feel confident that I am not passing on annoying build configuration requirements to my consumers.\r\n\r\nI would like my users to be able to just _use_ my library without needing to think about its dependencies (a major benefit to using npm/bower for frontend js). Ideally this is all they should have to do to use my library:\r\n\r\n```js\r\nvar widgets = require('react-widgets')\r\n```\r\n\r\nRight now to get this to work I either need to \r\n1. bundle all my code up into a monolithic \"dist\" build\r\n2. Tell my users how to handle building my libraries dependencies\r\n\r\nThe first is not feasible, as it destroys a lot of the benefits of using modules, means that users cannot consume my library ala carte. Right now you can do: `require('react-widgets/lib/DateTimePicker')` if you only want to use the date picker component in an app. Webpack/Browserify will include _only_ the code needed by the date picker, instead of sending all components to a client you only pay for the bytes you use.\r\n\r\nNumber two is not ideal, because its messy, brittle, and not user friendly. My users shouldn't have to understand how to build my project in order to use it, which means I need to provide modular code that works with the module -> bundle tools people are using. Me telling them to add an exception to their build step to handle a dependency they have no idea about is a hard sell."}}