I'm not convinced that this feature is worth supporting since it would only enable hacky overriding that probably shouldn't be done in the first place at the expense of extra bytes in every browserify bundle.

Well, three counter-arguments:

1. It's browserify's job to act this way when it is intended to be a port of node's module system.
2. We're talking about a mere 9 bytes here.
3. There are valid use-cases.

Okay, maybe 1. isn't a great argument as the readme already states that browserify provides a node-style require function, and not "node's module system for the browser".

As for 2., I already submitted a PR to browser-pack, which should implement it. And it's just an additional ,require:r that will be added in the minified source. Still some overhead, but nothing that should lead to a big argument.

Finally, the module I'm trying to compile is iriscouch/cqs. It uses defaultable as a way to provide default options. The actual functionality isn't even a hack, as it uses a documented feature of node's module system and uses the overwritten function for module-wide default propagation.

@substack, would it be possible for this to be optional or even un-documented?

We might argue about what constitutes "hacky overriding." What I know is that we are using @fb55's code in production and it works well. I agree with your point about spending bytes in every bundle; but I also agree with Felix's point that supporting a documented (stability = 5, locked) feature would be nice.

We will be okay either way, just asking you to reconsider. Thanks.

Localization library https://github.com/l20n/l20n.js by Mozilla also depends on module.require.

I'd like to see the Node.js platform supported in Browserify. Getting files relative to modules is important. 😟

Also, in this particularly awful case, we're using a Browserify bundle inside a require.js webapp; require.js gracelessly stomps the require variable (gee it'd be nice if these module-level variables more locally scoped by Browserify (& thus protected)). I'd expected module.require to be a cute dodge around the problem, but alas, tragedy.

Also missing: module.id, module.filename, module.loaded, module.parent, module.children.

I'm confused, since valid use of nodejs PUBLIC API is considered hacky approach ?!
This should be revisited as of 2018.
if that's an argument for you, webpack supports module.require

This is still an issue. browserify/browser-pack#19

Apollo Server also uses module.require:

https://github.com/apollographql/apollo-server/blob/bbcedd9fdc05a32104433f8d472c73a2f05aa51a/packages/apollo-server-core/src/utils/createSHA.ts#L5-L7