DEV Community

Discussion on: Having Moment.js Replacements Is Not Enough

Collapse
etienneburdet profile image
Etienne Burdet

It is an interesting idea, but I don't think this works—or at least really saves time—because tree-shaking is not the main thing at stake.

When switching to a lib like date-fns (fp flavor !) or Luxon, you're changing the way you manipulate dates too much: from a mutable moment.js instance to a set of pure functions and thus no mutable instance anymore. This way more important than tree-shaking.

Swapping moment.add(1, 'week') foraddWeek(1)(moment) just won't work and moment.addWeek(1) just doesn't solve anything. You would still have that mutable moment object that goes completly crazy in declarative templates with reactive bindings/stores.

There is no way around it, you will have to re-engineer everything at some point. In my opinion, the sooner the better and a wrapper would just add some spaghetti code.

Collapse
mimafogeus2 profile image
Miki Stanger Author

I completely agree, which is why I'm suggesting an additional, independent layer.
On your own code - you should totally work with date-fns, or luxon (or Chair :P)

BUT your dependencies are using, and many will keep using, moment. This means that moment is installed in addition to your choice, and you end up with your choice AND moment in your code.

The skeleton I'm offering is to be used by your dependencies.
For dependencies that use the moment global object, or use it as a peer dependency, the fix will be simple.
For other, you might have to configure Webpack somehow and/or rebuild them from the source, which might be a bit of a headache. BUT, it's the kind of a headache that could remove a lot of code from your project, and remove a dependency in an old project that recommends its users to use something else.

Collapse
etienneburdet profile image
Etienne Burdet

Ho my bad, I didn't realize you were talking about dependencies using moment.js—I though you would use the wrapper for not changing legacy code in your own project.

Yeah, rebuilding dependicies is totally not an option… Do you have any major package relying on moment in mind btw? (I don't use any…)

Thread Thread
mimafogeus2 profile image
Miki Stanger Author • Edited on

I hope to get into bundle optimization at work soon, where I'm almost sure I'll find moment lurking. I expect it to be in any project that has a date selector, time-related visualizations etc.
I know this has been the case in my previous workplaces where I took care to check that.

About rebuilding dependencies - that might actually be possible. Since npm usually installs the whole package - unbuilt code etc, included - it might be possible to create a script that takes selected packages, creates a link so moment will use the skeleton instead and rebuilds.
It could be a bit of a headache and take some time, but this script could only be ran every time you update one of those packages. Maybe one of the npm pre/post scripts could take care of that automatically.