3 ms·
I'm very familiar with that specific discussion. I find Sindre's arguments very convincing in regard to small modules. But he then assumes that small modules ~=
by crabmusket 3y ago
I'm very familiar with that specific discussion. I find Sindre's arguments very convincing in regard to small modules. But he then assumes that small modules ~= small NPM packages. That's where his argument fails, IMO.
Let's assume the alternative to "small NPM packages" is not "large NPM packages", but "small modules, vendored into my own repository". In this comparison, the benefits of small NPM packages become:
- Transient dependencies are automatically managed for you
- You can pull updates from the repository to get new features and bug fixes, and when you do this, as above, changes in transient dependencies are automatically managed for you
- The package gets a vanity download count on npmjs.com
There are meaningful tradeoffs here, but they're different to trying to rehash the benefits of modular code. Of course modular code is good. But packaging and distributing code is a whole different story.
EDIT: I'm having a bit of a reaction against the excesses of the NPM ecosystem at the moment. As, I think, are a lot of developers. I hope the pendulum swings from its current state more towards "fewer, better dependencies". Not towards "dependencies the size of a single function".
- crabmusket 3y agoDarn it, s/transient/transitive