5 ms·
Javascript library/toolkit modularisation do not goes this way. Mout, async or lodash are using a proper scheme to require('just/thefuction/youneed') and it's f
by 131hn 10y ago
Javascript library/toolkit modularisation do not goes this way. Mout, async or lodash are using a proper scheme to require('just/thefuction/youneed') and it's fine (no rollup will ever be needed). Polluting npm with dozen of one-liner is not a good idea (never forget left-pad)
* https://github.com/caolan/async/blob/master/CHANGELOG.md https://github.com/caolan/async/blob/master/CHANGELOG.md
* http://moutjs.com/ http://moutjs.com/
- insin 10y ago> Polluting npm with dozen of one-liner is not a good idea (never forget left-pad) The size or scope of left-pad wasn't the issue, the ability to unpublish modules which were depended on was [1] http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy http://blog.npmjs.org/post/141905368000/changes-to-npms-unpu...
- deleted 10y ago[deleted]
- dozzie 10y agoIn NPM registry, yes. But in Node.JS ecosystem, it was left-pad's scope combined with inability of the community to adopt seasoned sysadmins' tools, like custom repositories to build artifacts without ever needing to touch network (which is somewhat difficult to execute when you have dozens to hundreds of dependencies for a trivial project).
- insin 10y agoI don't think the number of dependencies per individual project is a critical factor when setting up an internal npm mirror for all your projects (e.g. with Nexus [1] where I work) or vendoring dependencies per project (e.g. `npm shrinkwrap --dev && shrinkpack` [2]) - you're either doing it or you aren't. [1] http://books.sonatype.com/nexus-book/reference/npm.html http://books.sonatype.com/nexus-book/reference/npm.html [2] https://github.com/JamieMason/shrinkpack https://github.com/JamieMason/shrinkpack