Webpack moment.js integration

[ichernev]

I'm from the moment.js (http://github.com/moment) team, and some of our users that are also your users voice concerns that because of the way webpack is implemented all moment locale files (currently 104) are bundled together, and that increases the size of what is downloaded to the browser.

Recently there was a suggested "fix" in the moment code (moment/moment#3344), but then we figured it broke the require mechanism for other environments.

Also we happen to have no instructions on how to use moment and webpack (like here: http://momentjs.com/docs/#/use-it/).

Can you please give us a hand by saying what is the right way to use moment with webpack, so it won't include all locale files if the user wants so. I hope this will decrease number of issues sent to both projects :)

Note: A webpack user suggested the following: moment/moment#1435 (comment) but nobody has documented it yet: moment/momentjs.com#269

[TheLarkInn]

@ichernev thank you so much for reaching out. ❤️❤️❤️❤️

We would be more than happy to help!!!

A cool idea 💡 that might be worth investigating is helping you guys create a 'example' or 'test' fixture of a small use case of webpack and moment together with one or many locales.

Pros:

• the fixture can serve as a point of reference for users in regards to implementation
• you can then run functional/integration smoke tests against this example for your test suite?

Thoughts?

[ichernev]

@TheLarkInn hello, thank you for the prompt response.

I like the fixture idea, we can take example from require.js documentation on our website, which mentions all the different (widely used) use-cases:

http://momentjs.com/docs/#/use-it/require-js/

Basically we'll need examples for:

• core only (no locales)
• core with a single locale (known in advance)
• core with all locales
• care + dynamically loading locales (if that is applicable to webpack at all)

[rafde]

@ichernev
new webpack.IgnorePlugin(/(locale)/, /node_modules.+(momentjs)/),

[Jessidhia]

@ichernev one problem is that your package.json points the jsnext:main entry point to your raw source code, instead of to a build of the source code that was emitted with ES6 modules. Your coding convention mostly keeps that from being a problem, but the actual issue is triggered by the relative require call.

In your main entry point, the mostly pre-bundled version, the relative require points to a locale folder that has actual locale data, so webpack happens to work there, but the require in the jsnext:main entry point points to a non-existing folder.

Now, because it is a dynamic require that webpack can parse, it actually creates a require context that can be modified by the ContextReplacementPlugin. The plugin can then be used to make it point to the correct folder, and restrict which imports are bundled.

This is how I dealt with it in my own codebase:

// restrict the extra locales that moment.js can load; en is always builtin
new webpack.ContextReplacementPlugin(/^\.\/locale$/, context => {
  // check if the context was created inside the moment package
  if (!/\/moment\//.test(context.context)) { return }
  // context needs to be modified in place
  Object.assign(context, {
    // include only japanese, korean and chinese variants
    // all tests are prefixed with './' so this must be part of the regExp
    // the default regExp includes everything; /^$/ could be used to include nothing
    regExp: /^\.\/(ja|ko|zh)/,
    // point to the locale data folder relative to moment/src/lib/locale
    request: '../../locale'
  })
})

This technically could be done with new webpack.ContextReplacementPlugin(/^\.\/locale$/, '../../locale', /^\.\/(ja|ko|zh)/), but there was no other way to make sure this would apply only to ./locale-relative requests made inside the moment module.

For dynamic loading of locales, moment would have to load locales with require.ensure instead of plain require. Webpack's parser supports conditional compilation for it with if (typeof require.ensure === 'function').

[ichernev]

@Kovensky thank you for this explanation.

The dynamic require use case is purely a user thing. I mean -- moment itself doesn't have interface to say "dynamically require a locale". It only has this hack to auto require locale on npm environment with require, and I believe it is the one causing trouble with webpack.

About you example with ContextReplacementPlugin -- where should this code be placed?

About the entry point being the ES6 code vs the bundled (es5) code -- I didn't understand if your solution works with both or just the ES6 code entry point. Also can you tell webpack which entry point to use? I mean do we need to change anything on moment end to make this work?

[schmod]

Here's a dumb question.

Is there any way Moment could export a separate entry point that doesn't include references to locales, so we could write import moment from 'moment/no-locales'; or require('moment/no-locales'), and subsequently/manually load the locales that we need?

This isn't going to be a great long-term solution, but it seems like it might make folks "happy enough" in the short-term, and should work seamlessly in just about any environment that understands CJS.

[TheLarkInn]

@ichernev just following up to ensure all your questions are answered. When you have a PR up we would be more than happy to look it over. Or if you are at a stopping point @Kovensky could assist you further.

[TheLarkInn]

@ichernev also:

About you example with ContextReplacementPlugin -- where should this code be placed?

This would an item inside of the plugins property in the webpack config: which is an array of plugin instances

webpack.config.js

const webpack = require('webpack');

const config = {
  /* ... */
  plugins: [ 
  new webpack.ContextReplacementPlugin(/^\.\/locale$/, context => {
    // check if the context was created inside the moment package
    if (!/\/moment\//.test(context.context)) { return }
    // context needs to be modified in place
    Object.assign(context, {
      // include only japanese, korean and chinese variants
      // all tests are prefixed with './' so this must be part of the regExp
      // the default regExp includes everything; /^$/ could be used to include nothing
      regExp: /^\.\/(ja|ko|zh)/,
        // point to the locale data folder relative to moment/src/lib/locale
      request: '../../locale'
    })
  })

  ]
  /* ... */
}

module.exports = config;

[ichernev]

@Kovensky @TheLarkInn so if I understand correctly, if the user specifies this blob in his config, the listed locales will be loaded in the "pack" and then using require a-la npm it will load them, but in case it requires something that is not "packed" it will fail?

If the user doesn't specify anything then all locales will be loadable with require (but this will increase the "pack").

I'm asking because we're discussing how to implement child locale loading: moment/moment#3336

Also is there away to go with @schmod suggestion. Basically define a separate npm/bower/git repo for webpack, that will have moment without locales and one with all locales and all locales separately and users can pack in a simpler way. I still don't understand how the packing will work in this case. Maybe the patch we reverted: https://github.com/moment/moment/pull/3344/files or the user has to somewhere specify all files he wants (so he either lists moment + a few locales, or moment-with-locales which contains all?).

[donaldpipowitch]

FYI: This problem isn't specific to moment.js. It would be nice to have a general recommendation how libs, which support multiple locales, should be used together with webpack. Other libs which I think of are https://github.com/andyearnshaw/Intl.js or https://github.com/angular/bower-angular-i18n. They don't have a require which includes all locales, but all of them need to be handled with some custom logic in some way. It would be nice to generalize the way how locale specific files are loaded.