Open SukkaW opened 1 year ago
I thought picocolors
was a joke in response to nanocolors
drama, but apparently it's now used by the author of nanocolors
in his projects (yes, all 3 projects you mentioned above have the same author, so it's just a personal preference, not a statistic).
Anyway, why not colorette
? (the project from which nanocolors
was originally copied)
Anyway, why not
colorette
? (the project from whichnanocolors
was originally copied)
The installation size of the colorette
(17 KiB) is 3x of picocolors
(5.66 KiB) while only 7% faster (https://www.npmjs.com/package/colorette?activeTab=readme#benchmarks). So I'd still prefer picocolors
.
Replace chalk@4.1.2 with picocolors
Relevant: https://github.com/chalk/chalk#why-not-switch-to-a-smaller-coloring-package
The installation size of the
patch-package
is reaching 2.33 MiB:(https://packagephobia.com/result?p=patch-package)
And here is the current npm dependency graph of the
patch-package
:https://npmgraph.js.org/?q=patch-package#zoom=w
I am wondering if we can reduce the installation size. And here is what I propose:
chalk@4.1.2
withpicocolors
picocolors
is "14 times smaller and 2 times faster than chalk", and is used by popular libraries like postcss, autoprefixer, and stylelint.fs-extra@9.1.0
with the Node.js built-infs
APIfs
API has been improving and evolving, Andpatch-package@8
is targeting Node.js 14+ already.rimraf@2.7.1
with the Node.js built-infs.rm
APIrm -rf
-likefs.rm
API, and it has been available since Node.js 14.14.0json-stable-stringify
withfast-json-stable-stringify
json-stable-stringify
is shipped with aJSON
polyfill (jsonify
). But we don't need theJSON
polyfill sincepatch-package@8
is targeting Node.js 14+.Together we can reduce the installation size of the
patch-package
by470
KiB.@ds300 What do you think?