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.
I'm a freelance front-end architect. I work with R&D, product and design teams to implement complex projects, emphasizing easily maintainable code and a good finish.
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.
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…)
I'm a freelance front-end architect. I work with R&D, product and design teams to implement complex projects, emphasizing easily maintainable code and a good finish.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 andmoment.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.
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.
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…)
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.