suggestion: move closer towards single-export files

The std/collections, std/async and std/fs modules are great. They’re structured so that each file essentially has one export. This makes the purpose of each file clear. They also have the added benefit of allowing the developer to keep dependencies lean but provide an alternative of importing multiple functions via their respective mod.ts files if needed.

On the other hand, other modules like std/streams and std/io do not follow this “single-export-per-file” rule. Instead, they’re further sub-categorised, which can sometimes be unclear, requiring the developer to read the file before understanding its purpose (io/files.ts comes to mind). Furthermore, multiple functions are grouped together. For example, if I want to use writeAll() from streams/conversion.ts, I also pull in 14 other functions/classes/interfaces.

For these reasons, I suggest we:

1. Move functions to their own files, where appropriate, along with testing counterparts. Async and sync siblings can remain in the same file.
2. Ensure a mod.ts file exists within each module that exports all functions/interfaces/classes within that module.
3. Point internal imports to their new locations.
4. Deprecate the old locations with a clear explanation and ample time until their removals.

This needs to be done for the following modules:

• tar
• bytes
• crypto
• datetime
• io
• streams
• testing?
• media_types
• encoding

[lino-levan]

I will restate my previous opinion that we should keep testing the way it currently is. Curious to hear what the broader community thinks.

[lino-levan]

I’d like to see what this would look like, but I’m a little bit skeptical as this seems like it will be a very noisy change. Would be a big fan of seeing a draft PR though.