I am very surprised too.
Having similar functions in a package is certainly a good decision. However, from a performance point of view, as long as we are not able to load a subset of a package, or have multiple packages in one repository, having small packages will have superior performance.
The only con of this is having another deps entry, which is a very minor thing, especially by considering how easily Pkg is able to handle the deps.
In Node packages, one can do this sort of import:
import IsURL: isurl
and the tree shaking tools like Rollup, Webpack, etc, will only import that in the package. This significantly improves the loading time performance.
In Julia, I have not read anywhere saying that there is a difference between import and using, in terms of loading performance.
Having small packages removes the need for using tree shaking tools.
Another aspect of this topic is the functions that don’t belong to any other package with similar functionality, and from a modularity perspective, it is always a better decision to move the generic parts of a package to another module, so everyone can use them.
Here I am very surprised by that comment that was saying some code copying is good in Julia!
Take this simple julia_versionnumber function for example. This fetches the nightly version of Julia from the repository. My feeling says that there is no better place other than Julia repository itself (in version.jl) that this should go.
However, there is always some inertia for adding functions to the Base, even if they are working exactly with the Julia repository! and now, I have no other options to move this to a repository of itself and call it JuliaVersionNumber or something.