If you read the official Deno manual, you'll notice that the author advices you to contain all dependecies into one file.
Similarly, if you're cre...
For further actions, you may consider blocking this person and/or reporting abuse
The removal of
deps.tsandmod.tsworks well with a module alias file. I use module aliases for my dependencies and for folders in my projects (e.g. if I had autilsfolder with a logger in it I would configure an alias to use@utils/logger.ts)I mean, if you have a dependency, I think there’s a pretty high chance you’re gonna use it somewhere, so it’ll be compiled anyway.
So are you saying if I import A from X, I'm going to use B, C, D, E, F, G, H anyway? If that is true, why would the lodash community wanted modularize lodash packages?
No, I’m saying if you have B, C, D, E, F, G and H in there you’re gonna use them anyway.
I don't disagree with that, but you have to know that this problem applies to every level of dependencies, so even if you're gonna use everything module, you cannot make sure that the author of the library that you're importing are going to utilize every functions that imported from the
mod.tsof another library.Eventually this creates a snowball effect, little by little, all those unused imports will take up a significant portion if not most of the compile time.
I’m talking about modules, not functions. You are right that you can’t be sure that a dependency will use every function of all its dependency, but in most cases it won’t matter, as all the functions will be compiled no matter how many you use.
At first I wasn't convinced
But the idea of separating the dependencies while keeping the possibility to update them without doing it for each file is well thought-out
This pattern should be proposed to more people, in the end it doesn't bring any disadvantages.
EDIT: this is very time consuming, not recommended.
Anyone else wondering what happened between the end of this comment and the edit. What did this person see.
Hi @oganexon , thanks for the reply. But I have a question for you, isn't longer compile time time-consuming too?
I meant to divide each dep in it's own file.
My module only does one thing and the cli has its own dep in the file so I already divided the deps
So overall I support your idea to provide a
modfolder but not adepsfolderTrue, I might have taken that way too far lol
Sometimes it might make sense. If your project is a bunch of functions that may or may not be used, this totally makes sense. But if you're project is something like Oak, then a fair amount of it will be wanted, and maybe other parts will be added on, and those dependencies can be isolated if needed.
Or if your project is an enterprise app, like mine, then you most likely want most, if not all, of the dependencies.
Compile time isn't a big deal (to me). It's a one time thing for each new launch. And such a decision imposes architecture which may or may not be what I'm looking for.
The compromise I've made in my public Deno libraries is to allow each major feature to be independently loaded, but also have a mod.ts that loads them all if someone so chooses. I tend to choose it.
It's might be true for backend, but for frontend development, a fast feedback loop is very crucial, especially most of frontend developer's time is spent on styling and layout rather than logic.
You mention some compile time benchmarks you ran. I'd be interested if you'd add some examples to your article to highlight your point.
Will the example provided in this repository helps? github.com/wongjiahau/deno-mod-ben...
Yup! Thanks