Installing package from npm takes a long time about concurrently

[jpolo]

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.

[Gikkman]

I've researched for alternative libraries, but I haven't found any perfect replacements.

• Luxon is DateFormat compatible, but doesn't include Typescript types (installed from @types). Is a pretty large library, but installs quickly in my tests. Requires to wrap the Date object in their own type.
• date-format is small, is DateFormat compatible, but they have no Typescript support (would require a manual d.ts declarations file). Easy to use.
• date-and-time is small, supports Typescript, but is not DateFormat compatible (they use YYYY over yyyy for example). Easy to use
• Days.js is very small, support Typescript, and is DateFormat compatible. But they formatting function requires some plugin use, and I don't know how you'd get the library to work in both Node and Browser mode, since it requires different plugin loading behaviors.

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

[gustavohenke]

Interesting find. TIL about --timing flag.

I see this problem (or similar?) has actually been reported to date-fns before:
date-fns/date-fns#3067
date-fns/date-fns#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?

[k2snowman69]

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:

1. A breaking change to --timestamp-format
2. Intl.DateTimeFormat is very limiting compared to date-fns (so you'll get some heat)
3. Not really a good way to enable/disable Intl.DateTimeFormat options via the command line if someone wanted to customize the date

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!