3 ms·

A more useful bot would be named Undependabot. Cuts complexity caused by the dependency bloat by suggesting to remove random dependencies and linking to http://

by jraph 4y ago

A more useful bot would be named Undependabot. Cuts complexity caused by the dependency bloat by suggesting to remove random dependencies and linking to http://vanilla-js.com/ http://vanilla-js.com/. Flags any PR that introduces new dependencies, and computes the cost in time and money these new dependencies should cost in the long term, and the time and bandwidth usage it adds to each (CI) build. Adds badges to developers and teams that reduce their dependencies or have few or none. Rejects any PR introducing (transitive) dependencies to packages from jonschlinkert.

chrismorgan 4y ago
Mind you, adding dependencies does not imply increasing build artefact sizes. Suppose A depends on B and C, and B and C contain similar functionality, then collaborate to extract that into D, so that A ends up with one more dependency, but less code net. (This is the theory of the tiny package philosophy widely found in npm. But in practice, they often seem to clog things up awfully with runtime type checking and the likes, or just adding a pointless level of indirection, so that they make things worse. But the underlying idea is sound.) —⁂— For the rest, most of the pieces already exist and are not particularly difficult to put together, though a more polished presentation of a holistic experience (if you’ll pardon the expression) could be desirable. For suggesting dependencies to remove and flagging undesirable dependencies, that’s entirely a data problem: you want another audit/code review/advisory database, really. (You could take it further and identify automatic code translations, but that’d be quite a bit more work, though again the bones that you need generally already exist.) For pointing out dependency costs: such metric monitoring is already widely used, especially in larger projects that want to catch regressions immediately.

by jraph 4y ago

chrismorgan 4y ago

Mind you, adding dependencies does not imply increasing build artefact sizes. Suppose A depends on B and C, and B and C contain similar functionality, then collaborate to extract that into D, so that A ends up with one more dependency, but less code net. (This is the theory of the tiny package philosophy widely found in npm. But in practice, they often seem to clog things up awfully with runtime type checking and the likes, or just adding a pointless level of indirection, so that they make things worse. But the underlying idea is sound.) —⁂— For the rest, most of the pieces already exist and are not particularly difficult to put together, though a more polished presentation of a holistic experience (if you’ll pardon the expression) could be desirable. For suggesting dependencies to remove and flagging undesirable dependencies, that’s entirely a data problem: you want another audit/code review/advisory database, really. (You could take it further and identify automatic code translations, but that’d be quite a bit more work, though again the bones that you need generally already exist.) For pointing out dependency costs: such metric monitoring is already widely used, especially in larger projects that want to catch regressions immediately.