http, tls, stream, test, build: refactor lib/ underscore files into directories

[devsnek]

this is really just a small cleanup, no actual functionality was
changed. I think this would mostly be a nice change for people who are
new to the node.js source, as peeking into /lib with all that can be a
bit confusing unless you understand how modules's builtin resolving works.

This will also require a change to nodejs/github-bot

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

http, tls, stream

[mscdex]

unless you understand how NativeModule's builtin resolving works

I don't understand this part. It works the same as loading a module from disk. require('tls') loads lib/tls.js, require('internal/freelist') loads lib/internal/freelist.js, etc. There is nothing magical when it comes to resolving built-in modules.

[apapirovski]

Sorry but I'm -1 on this — seems like churn for pretty much no benefit. I would understand if we literally had 10s or 100s of files here but that's not even close to being the case. This also breaks anyone using --expose-internals (even if I have little sympathy for it). Changes like this can make backporting harder than it needs to be as well.

Given we haven't been able to come to an agreement on creating sub folders for tests, I don't see how the core code is going to be easier.

[devsnek]

@mscdex when i first encountered /lib i was confused about why require('_http_common.js') didn't work until i had snooped out the entire module resolving pipeline and found the static list of builtin modules

[mscdex]

@devsnek If anything, that sounds like more of a documentation change PR for the contributing guide or something. This PR does not change how built-in modules are loaded, so the same "issue" still exists...

[devsnek]

@mscdex thats a good point, maybe i'll make a pr to that as well, but this is also just a nice change. I agree it isn't needed, but it keeps the source organized, which is always a nice thing.

[mscdex]

@devsnek Maybe, but IMHO it's not worth the potential breakage.

[jasnell]

At this point, I'm -1 on this due to the extremely likely chance this will break existing userland code... which is unfortunate. What I'd like to see us be able to do is move these _-prefixed modules into internal at some point instead, then do a runtime deprecation of the user-requirable versions.

Even if this PR does move forward, a deprecation for the current require paths would be a requirement to land.

[mcollina]

There is #11957 that is prior art on this.

[devsnek]

I can definitely add stubs, and maybe moving them to internal is a good idea to give more freedom in the future

[BridgeAR]

It seems like there are multiple -1 and it is not likely that this is going to land. I am closing this therefore.