Wiuldnt implementing those be trivial? They are hardly going to be "too slow" like file copy might be, and with the JS love of small packages this should already be a solved problem.
There most certainly are already packages that do this, as well as countless projects with a util.js file implementing a hodgepodge of such functions that are standards in many languages. But as a programmer I would say my biggest complaint against JS is the miserably small standard library. Thus every project has its own set of dependencies that have their own APIs. Two projects from different JS ecosystems are as different as projects in different languages altogether.
There are trade offs to be sure, but I prefer the languages (and in this case platforms) that have batteries included.
> Thus every project has its own set of dependencies that have their own APIs.
Yes, this means that if your project depends on ten other projects, and all ten projects implement their own copy-file routine, your project will end up with ten copy-file routines.
When working on a project and you need to copy something for the first time, you shouldn't have to do:
* Ok I need to copy... What npm package does that again?
* search NPM for copy
* figure out which package is "best"
* npm i some-copy-package
* require("some-copy-packge")
* do thing
For the first one, what about error handling? You have to handle errors by both the read and write stream, and also most people will want a callback when everything is done, so you have to handle that event, too.
I'm not sure how fs.copyFile is implemented, but file copying is not the same as reading the contents of file and then writing it into another file, which is easy to implement. There are also permissions, extended attributes, access control lists, etc. And then there are CoW file systems such as APFL that can optimize copying referencing the original data instead of physically copying it.
There are trade offs to be sure, but I prefer the languages (and in this case platforms) that have batteries included.