open-cli-tools
Installing package from npm takes a long time
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 installing concurrently was the main culprit. Or rather, the date-fns library it has as a dependency. I ran the installation instruction again, and supplied the --timing flag, to get some data:
$ npm i -D --timing concurrently
--- Some logs cut for longevity npm timing idealTree:buildDeps Completed in 1226ms npm timing idealTree:fixDepFlags Completed in 1ms npm timing idealTree Completed in 1305ms npm timing reify:loadTrees Completed in 1306ms npm timing reify:diffTrees Completed in 5ms npm timing reify:retireShallow Completed in 1ms npm timing reify:createSparse Completed in 346ms npm timing reify:loadBundles Completed in 0ms npm timing reifyNode:node_modules/wrap-ansi Completed in 413ms npm timing reifyNode:node_modules/is-fullwidth-code-point Completed in 417ms npm timing reifyNode:node_modules/string-width Completed in 417ms npm timing reifyNode:node_modules/concurrently/node_modules/supports-color Completed in 421ms npm timing reifyNode:node_modules/concurrently/node_modules/has-flag Completed in 421ms npm timing reifyNode:node_modules/get-caller-file Completed in 422ms npm timing reifyNode:node_modules/tree-kill Completed in 422ms npm timing reifyNode:node_modules/require-directory Completed in 427ms npm timing reifyNode:node_modules/regenerator-runtime Completed in 429ms npm timing reifyNode:node_modules/escalade Completed in 430ms npm timing reifyNode:node_modules/emoji-regex Completed in 434ms npm timing reifyNode:node_modules/cliui Completed in 434ms npm timing reifyNode:node_modules/y18n Completed in 436ms npm timing reifyNode:node_modules/spawn-command Completed in 435ms npm timing reifyNode:node_modules/yargs-parser Completed in 453ms npm timing reifyNode:node_modules/rxjs/node_modules/tslib Completed in 463ms npm timing reifyNode:node_modules/shell-quote Completed in 463ms npm timing reifyNode:node_modules/concurrently Completed in 524ms npm timing reifyNode:node_modules/yargs Completed in 537ms npm timing reifyNode:node_modules/@babel/runtime Completed in 605ms npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk 939ms npm timing auditReport:getReport Completed in 944ms npm timing auditReport:init Completed in 0ms npm timing reify:audit Completed in 944ms npm timing reifyNode:node_modules/lodash Completed in 939ms npm timing reifyNode:node_modules/rxjs Completed in 1504ms npm timing reifyNode:node_modules/date-fns Completed in 35361ms npm timing reify:unpack Completed in 35363ms npm timing reify:unretire Completed in 0ms npm timing build:queue Completed in 2ms npm timing build:link:node_modules/tree-kill Completed in 21ms npm timing build:link:node_modules/concurrently Completed in 23ms npm timing build:link Completed in 23ms npm timing build:deps Completed in 25ms npm timing build Completed in 25ms npm timing reify:build Completed in 25ms npm timing reify:trash Completed in 0ms npm timing reify:save Completed in 36ms npm timing reify Completed in 37106ms
added 23 packages, and audited 309 packages in 37s
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.
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
YYYYoveryyyyfor 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).
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:
- A breaking change to
--timestamp-format - Intl.DateTimeFormat is very limiting compared to date-fns (so you'll get some heat)
- 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!
Hey! This is now fixed in v9.0.0. https://github.com/open-cli-tools/concurrently/releases/tag/v9.0.0