12 Matching Annotations
- Mar 2021
-
medium.com medium.com
-
-
If the only realistic consumer of a package is the monorepo, and you can’t realistically see normal users installing that 1 package out of 138 other packages in that repository, there’s probably no need to have it as a separate package. Ideally it would be better to let a user install 1 package that contains everything, and reduce the overhead.
-
-
www.chevtek.io www.chevtek.io
-
-
he goes on to say that simple functions should not be packages because they are too small.
-
"Functions Are Not Packages" - Well why not?
-
I would much rather have a "cosine" module than a "trigonometry" module because chances are good I only need a small fraction of the utilities provided by the larger trig module.
-
For one, anyone using this module would automatically benefit from any future performance improvements without having to do anything themselves.
-
Second, I don't agree that there are too many small modules. In fact, I wish every common function existed as its own module. Even the maintainers of utility libraries like Underscore and Lodash have realized the benefits of modularity and allowed you to install individual utilities from their library as separate modules. From where I sit that seems like a smart move. Why should I import the entirety of Underscore just to use one function? Instead I'd rather see more "function suites" where a bunch of utilities are all published separately but under a namespace or some kind of common name prefix to make them easier to find. The way Underscore and Lodash have approached this issue is perfect. It gives consumers of their packages options and flexibility while still letting people like Dave import the whole entire library if that's what they really want to do.
Tags
- all or nothing (granularity of control)
- granularity of control
- modularity
- benefiting from upstream development
- argument for
- small units/components/modules/libraries/packages/projects
- well-written
- why not?
- allowing developer/user to pick and choose which pieces to use (a la carte, not all or nothing)
- advantages/merits/pros
- micropackages
- can it really ever be too _?
- flexibility to use the tool that you prefer
Annotators
URL
-
-
github.com github.com
-
www.sitepoint.com www.sitepoint.com
-
Again, this is all opinion-based, and due to the sheer number of developers who rely on this technology as their bread and butter, sub-communities and religiousness forms around patterns, anti-patterns, practices, de-facto standards, micro-packages, polyfills, frameworks, build-tools, etc.
-
While various shortcomings of the standard run-time library are the obvious, immediate reason for the creation of micro-packages
-