-
Notifications
You must be signed in to change notification settings - Fork 596
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suggestion: move closer towards single-export files #2936
Comments
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. |
I have been thinking about this one recently. I don't think flags really applies here given that flags literally only has one (non-type) export. I also have similar feelings for |
Agreed. I've removed it from the list.
The counterarguments would be those mentioned in the initial comment. I'm fine with either option. Let's see what others think. |
Are there any benefits to be had by restructuring |
I will restate my previous opinion that we should keep testing the way it currently is. Curious to hear what the broader community thinks. |
@kt3k, WDYT? |
I'd prefer to keep the current structure of Also I think people don't care much about load footprint of test utilities than other non-testing utility. Even if we provide |
These are all now complete. |
The
std/collections
,std/async
andstd/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 respectivemod.ts
files if needed.On the other hand, other modules like
std/streams
andstd/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 usewriteAll()
fromstreams/conversion.ts
, I also pull in 14 other functions/classes/interfaces.For these reasons, I suggest we:
mod.ts
file exists within each module that exports all functions/interfaces/classes within that module.This needs to be done for the following modules:
The text was updated successfully, but these errors were encountered: