Add a plugin to webpack config w/o ejecting

[orditeck]

Is that possible? I'm using moment and it loads all the locales (so moment takes 200kB instead of 50kB in the build), the current fix for more than one year seems to be to exclude the locales via webpack using:

new webpack.ContextReplacementPlugin(/moment[\\\/]locale$/, /^\.\/(en)$/)

I tried to add it manually to /node_modules/react-scripts/config/webpack.config.prod.jsand it works but I can't do that, and I don't want to eject.

[gaearon]

Maybe it's time for somebody to fork moment and make it Webpack-friendly if they'd rather not fix it? It's really not right that a library requires changes in the config.

And no, we don't intend to allow modifying Webpack configs as this defeats the purpose of this tool. Your best bet would be to bring this up with Moment maintainers (this issue has been affecting people for years) or fork it.

[orditeck]

Ok thanks. It's been pointed out a long time ago to webpack moment maintainers but... well. I'll try to find something else. Thanks!

[gaearon]

I think it's more of a problem with Moment than with Webpack.

[orditeck]

Oh, yeah, my mistake! I meant "momentjs maintainers".

Seems like they're working on it after all! webpack/webpack#3128

[gaearon]

FWIW if you need something similar to Moment but not suffering from this issue, I recommend date-fns.

[orditeck]

@gaearon thanks for the suggestion and the time you're taking to reply to me, that's what I'd use as I discovered it while looking for an alternative to moment but the date/timepicker I'm using requires moment. I tried to find one using date-fns but haven't found any, I'll try to search again. Maybe I should create one but I'm not sure it'd fit in the current budget of my client 😊

[thien-do]

@orditeck I used to be in your situation... all I need is a simple date picker and 200 of KB from momentjs come into my app. Now in my simple cases, I just use select boxes..

However, in complex case that a date picker is a must, I suggest you to consider libraries that are not 'react' yet. It is actually quite easy to use any libraries with react, because they are just JS after all.

If you already have jquery, then https://github.com/amsul/pickadate.js might be a good choice since it is not depend on momentjs. I think you can even find one that is not depend on any thing at all.

Ps. of course create a new one for community is always appreciate =))

[ezhlobo]

@orditeck hi. I forked this repository and added the possibility to modify webpack configs. You can take a look at it here: https://github.com/ezhlobo/react-scripts

[jquense]

@gaearon seems like react-scripts could help protect the user transparently here by adding the context replacement plugin. I generally agree with you that this is moment's problem. However, pragmatically:

1. Moment is the defacto community standard for a datetime library
2. This problem has existed for a long time and doesn't look like it's gonna get addressed quickly from moment's end.
3. dateFns is a great probject, but lacks the years of institutional hardening and i18n robustiness of moment, making it a suboptimal choice for folks doing meaningful datetime/i18n work
4. The ease of someone doing the wrong thing is almost frictionless and the cost large.
5. react-scripts could fix this without allowing config changes by adding a special case for moment.

I reallly understand not wanting to have a bunch of special cases for user libraries, However maybe it's worth making an exception for community projects that are used extensively?

[jquense]

e.g. https://webpack.js.org/plugins/ignore-plugin/#ignore-moment-locales