https://github.com/micromatch/to-regex-range/pull/17

This PR replaces is-number package with a one-liner with identical code. It passes all the tests (npm run test).
This tiny change saves 440GB weekly traffic:


Package size report
===================

Package info for " to-regex-range@5.0.1 ": 33 kB
Released: 2019-04-07 0637.03 +0000 UTC (277w2d ago)
Downloads last week: 43,837,006
Estimated traffic last week: 1.5 TB

Removed dependencies:
- is-number@7.0.0 : 10 kB (30.06%)
Downloads last week: 43,875,245
Downloads last week from " to-regex-range@5.0.1 ": 43,837,006 (99.91%)
Estimated traffic last week: 440 GB
Estimated traffic from " to-regex-range@5.0.1 ": 440 GB (99.91%)

Estimated package size: 33 kB → 23 kB (69.94%)
Estimated traffic over a week: 1.5 TB → 1.0 TB (440 GB saved)

#programowanie
59963ecc-f4c2-4734-9c0f-75b7992b302b
b18fb017-64d6-40ec-8974-264d258a3613
10

Komentarze (10)

@Deykun just JS & npm things

@serel dla pierwszych ssd to node_modules mialy znaczenie bo szybko zabijal ich zywotnosc. Aktualnie tam moze 2gb i nikt nie daje o to jebania

@Deykun akademicka dyskusja z bluzgami i subtelnymi uwagami ad-personam. Klasyczne 80% developmentu xD

@wombatDaiquiri ja się z typem na końcu nie zgadzam, ale w sumie jego wyjaśnienie, że wszyscy implementujący swoje isNumber mają je w swoim kodzie i niech będzie duża paczka której podpaczki też to robią, to jakby wszystkie używały najpopularniejszego utilsa do tego to na koniec by było mniej kodu. To nie jest świat w którym chciałbym żyć, ale ta logika ma sens.

@wombatDaiquiri - ma to sens

this PR is to reduce network bandwidth because npm ships stuff as tarballs (and not source directly) and to reduce supply chain / dependency graph (it takes time to parse it + adds potential security risks)

@Deykun @koszotorobur jest dużo takich miejsc w kodzie, które można napisać lepiej. Ale podczas developmentu, żeby być efektywnym, potrzeba też „people skills” których tutaj ewidentnie zabrakło.

@wombatDaiquiri - umiejętności interpersonalne są niezwykle ważne - a im większy projekt i więcej ludzi jest w niego zaangażowanych tym są ważniejsze.

Niemniej jako owner projektu czasem trzeba podjąć decyzję wiedząc, że ona nie zadowoli części zaangażowanych w projekt ludzi.

Nie da się każdego zadowolić a umiejętność podjęcia decyzji i zakończenie jałowej dyskusji to cechy dobrego ownera.

W tym konkretnym przypadku faktycznie zabrakło miękkich umiejętności ale ostatecznie z technicznego punktu widzenia wprowadzona zmiana ma wystarczający sens i nie ma o co kopii kruszyć

Zaloguj się aby komentować