Why not combine it all? Because collisions. Even in Rust, the collision between a tokio::sync::Mutex and a std::sync::Mutex (and some projects, including me, prefer parking_lot::Mutex) and all are subtly different.
So chances are you have a dependency that collides with you. Or with each other. (Though if this means that JS-land will have fewer tiny, crappy dependencies (cough cough leftpad), it may end up being a benefit…)
Now, the argument for full qualification instead of relative paths is a very good one and that is well worth doing.
As per Python, “Namespaces are a honking good idea… use more of them!”
EDIT: full qualification is so good I just refactored my stuff to that, so thank you!
Combine everything is a viable approach if the ecosystem chooses it. This is how Ruby works, and it’s fine because people know they need to “own” a module namespace to use it.
Addressed your comment RE collisions (updated article), TLDR it is non-issue because all exports are manually mapped, so you can prevent collision by aliasing the exports.
I like the explicit importa too. My preferred style is:
Libraries generally stick to one-level names. Example std::HashMap instead of std::collections::HashMap.
Don’t do local aliases. Spell out std::HashMap on every use.
I like this because when reading code I see quite explicitly what I am using and types have the same name everywhere. foo::Error rather than guessing what someone aliased it in the use foo::Error as FooError.
The article lists as one of the main starting points, a “constant guess game when trying to figure out how many ../ to add” - how is this a problem? Modern tools don’t have a problem sorting through 10,000 files in my sources, or million files under node_modules and finding out exactly which “SQLQueryMethods” I wanted, or to offer me a choice.
I don’t need to either remember where they came from or where they are - it says so right there, at the top of the file. My tools will also helpfully collapse all the imports by default for me, so only if I need to know the location, I can take a quick look.
And the update to the article says, “you can just remap things”. Well, you just created me a problem where I had none - I didn’t need to know where my SQLQueryMethods was, but now I need to find out what its name is before I can import it. Why did I need that?
Another problem is scope. I need to import all the components in a single place? That’s mighty complicated if the project is non-trivial. There’s just too much stuff. Perhaps a hybrid approach, where I added the barrel file as a “aggregated dependency import” to my components, models, services, bits, parts, would help.
But even then I don’t really see much benefit, a smaller section of code will probably not see that many imports, so I can just keep them right there in the file to see them.
And if you’re pushing your code to frontend, now you also have to deal with bundling code you potentially don’t even need? Okay, tree shaking should take care of that even with barrel files, but it’s still unnecessary.
Why not combine it all? Because collisions. Even in Rust, the collision between a tokio::sync::Mutex and a std::sync::Mutex (and some projects, including me, prefer parking_lot::Mutex) and all are subtly different.
So chances are you have a dependency that collides with you. Or with each other. (Though if this means that JS-land will have fewer tiny, crappy dependencies (cough cough leftpad), it may end up being a benefit…)
Now, the argument for full qualification instead of relative paths is a very good one and that is well worth doing.
As per Python, “Namespaces are a honking good idea… use more of them!”
EDIT: full qualification is so good I just refactored my stuff to that, so thank you!
Combine everything is a viable approach if the ecosystem chooses it. This is how Ruby works, and it’s fine because people know they need to “own” a module namespace to use it.
Addressed your comment RE collisions (updated article), TLDR it is non-issue because all exports are manually mapped, so you can prevent collision by aliasing the exports.
I like the explicit importa too. My preferred style is:
std::HashMapinstead ofstd::collections::HashMap.std::HashMapon every use.I like this because when reading code I see quite explicitly what I am using and types have the same name everywhere.
foo::Errorrather than guessing what someone aliased it in theuse foo::Error as FooError.The article lists as one of the main starting points, a “constant guess game when trying to figure out how many ../ to add” - how is this a problem? Modern tools don’t have a problem sorting through 10,000 files in my sources, or million files under node_modules and finding out exactly which “SQLQueryMethods” I wanted, or to offer me a choice.
I don’t need to either remember where they came from or where they are - it says so right there, at the top of the file. My tools will also helpfully collapse all the imports by default for me, so only if I need to know the location, I can take a quick look.
And the update to the article says, “you can just remap things”. Well, you just created me a problem where I had none - I didn’t need to know where my
SQLQueryMethodswas, but now I need to find out what its name is before I can import it. Why did I need that?Another problem is scope. I need to import all the components in a single place? That’s mighty complicated if the project is non-trivial. There’s just too much stuff. Perhaps a hybrid approach, where I added the barrel file as a “aggregated dependency import” to my components, models, services, bits, parts, would help.
But even then I don’t really see much benefit, a smaller section of code will probably not see that many imports, so I can just keep them right there in the file to see them.
And if you’re pushing your code to frontend, now you also have to deal with bundling code you potentially don’t even need? Okay, tree shaking should take care of that even with barrel files, but it’s still unnecessary.