Consider replacing moment/lodash with lighter alternatives, or removing

[43081j]

pkg-size claims this package is ~14MB. most of that comes from lodash and moment

i wonder if we could:

• Remove lodash (most collection helpers exist natively now)
• Replace moment with date-fns
  • or we could also remove moment and rely on consumers dealing with Date objects themselves

it'd be a breaking change of course

its fairly low priority but the plugin does exist in various prod dependency lists, so a reduction in install size/footprint would still be great

a quick search suggests quite a lot of consumers do use moment (but not lodash so much). primarily for copyright dates etc. it may be that it'd be too much of a pain to change it now that people have already written templates using moment.

[mjeanroy]

Thanks for opening the discussion.

To be honest, I would also like to remove these dependencies for lighter alternatives. My main concern is that it could be a big breaking change (especially moment I guess), so I did not want to take the risk.

When I wrote the first version of this plugin, I needed these dependencies for my own usage (that's why I wrote this plugin in the first place btw) and these dependencies were quite common, so it was not a big deal.

Eight years later, I genuinely think it was a mistake, but hard to remove/replace it now.

Any idea how we could move forward without breaking build?

[43081j]

if it were up to me, i think i'd create a breaking version (new major) which has neither of them and rely on the consumer passing data in instead

you also use lodash for the templating right now. we could pull that in directly (from lodash.template), although its still a fairly chunky dependency (66K).

or if we can find a lighter alternative that does the same syntax, opt for that

by the looks of it, a lot of consumers just interpolate their own expressions anyway (rather than using the template syntax).

that's another choice too, just tell consumers to use template strings and we give them access to some context object so they can access things like context.pkg.name.

but if we choose to keep things roughly as is, i feel like it'll be fairly easy to drop the two dependencies without annoying too many people (and those who don't have time to rework their templates can stay on the old version)