Thanks for the article. I generally agree on that. util.deprecate() had better not been exposed. Node’s job would be to expose the CLI flag for userland modules, as you’ve already mentioned. This way, a node user would have a uniform API ( — trace-deprecations) but the implementation and console output would be up to a userland module which is much more flexible than node core.
I don’t agree on fs.readFile(), though, because it’s one of node’s core APIs I use the most. Pushing those basic things to npm makes the life of a node core maintainer easier, but also puts a burden on all node users. Because then you would have a lot of similar APIs, doing almost the same thing. But you would always need to look up the documentation if you’re switching between projects because you can’t remember the exact API anymore. It would probably be enough for most users to only pass strings to readFile instead of file descriptors, I guess.
I like the idea of curation. Have you thought about putting node’s core modules on npm? This way, they could be separately versioned, but you would still have that promise of a uniform API.
There’s also another aspect here which is not directly related to node, but to frontend development. If we had a smaller set of curated APIs (like node’s core modules are), our frontend builds would be smaller. When there are hundreds of modules that do almost the same thing, you will end up with a bundle that contains a lot of duplicated logic, because everyone is using a slightly different module. We, the webpack team, encourage people to use node’s core modules whenever possible, because they will be swapped out only once with the browser-compatible versions.