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.
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.