Closed Gikkman closed 1 week ago
I've researched for alternative libraries, but I haven't found any perfect replacements.
YYYY
over yyyy
for example). Easy to useI could probably fix up a PR for switching to another formatting library that is smaller, if it would be interesting. But I'd like some input on what concessions would be acceptable (if any).
Interesting find. TIL about --timing
flag.
I see this problem (or similar?) has actually been reported to date-fns before: https://github.com/date-fns/date-fns/issues/3067 https://github.com/date-fns/date-fns/issues/2479
...but no satisfying solution yet (I think?).
My preference among the options you listed would be date-format
, given it's rather popular, small in size and API surface (therefore easy to type ourselves). There might be more things to consider before committing to it though (bugs/security/maintenance quality).
@paescuj do you have opinions?
There are other causes of heavy weight : rxjs. Imho, concurrently would benefit a great performance improvement if it just distribute a tree shaken optimized with no npm dependency cli bundle.
I don't see a major interest in distributing the library, but if you need to, it could be done in another package "core" which can hold the references to the heavy dependencies.
Alternative (and a bit hacky) but could open to removing the dependency all together is abusing Intl.DateTimeFormat:
const date = new Date("2024-01-02T00:04:05.006Z");
console.log(
new Intl.DateTimeFormat('bo', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
minute: '2-digit',
hour: '2-digit',
second: '2-digit',
fractionalSecondDigits: 3,
timeZone: 'UTC',
hourCycle: "h23"
}).format(date),
);
// Expected output: "2024-01-02 00:04:05.006"
Works on node 14.20 and above (tested using runkit).
The main cons with this option is it's:
--timestamp-format
Low probability this idea would be taken seriously but in case someone else stumbles on this issue wondering if Intl.DateTimeFormat can be swapped in, here ya go!
Hey! This is now fixed in v9.0.0. https://github.com/open-cli-tools/concurrently/releases/tag/v9.0.0
Awesome. Thank you for your hard work <3
I noticed earlier today when I cloned an older project I have that running
npm install
took quite a long time. I drilled down in to why, and it turned out that installingconcurrently
was the main culprit. Or rather, thedate-fns
library it has as a dependency. I ran the installation instruction again, and supplied the--timing
flag, to get some data:Notice how the step to
reifyNode:node_modules/date-fns
(which I think is unpacking the downloaded library) took a little over 35s, of the total 37s. I've re-ran the same command several times, and the results are pretty consistent.I am not sure what is causing it to take such a long time, but I found an few old issue here talking about
date-fns
(#329) and it being imported in its fullness. Maybe that could be the problem here too, since the npm installation cannot tree shake the dependency.