any reason against using the deps.ts approach?
It seems that the
Deps.ts approach is not recommended anymore since jsr - however I fail to see why. What's the benefit of using the import map and falling back into the package.json problems instead of having a Deps.ts file? The only thing I can see is that the module specifiers can thus be compatible with non-deno code...6 Replies
the benefit is that you can now do proper dependency resolution. With the
deps.ts pattern it was very common to pull in many different versions of the same library. Like you have dependency A which pulls in some-lib@1.0.0 then you have B in your deps.ts file which pulls in some-lib@1.2.0. With the deps.ts pattern you're always going to end up with multiple versions of the same library, unless you ensure that every single dependency that you use, uses the exact same version as you in your project. This is automatically handled with JSR.
The other downside people ran frequently into with deps.ts , is that you can never use import map aliases in library code. SInce http modules have no concept of a package boundary, all code must share the exact same aliases, which would often leave to name clashes etc.I see, so this is pretty much a non issue with small dependency trees or trees that you fully control. Thanks 🙂
Third downside is with deps.ts will cause all referenced libraries to be loaded and initialized whether they are used or not by the main entrypoint. If using dynamic imports that problem can be amplified. With import maps you can reference as many libraries as you like, and they will only be loaded on-demand.
I’m stuck on an embedded deno 1.38.1 for now, so JSR isn’t an option quite yet. I have been trying out using import maps, and resolving jsr-like e.g.
@std/async names to https/deno.land. Are there any major differences between this and using JSR? I was thinking it’d let me get most of the benefits without having to upgrade deno, or at least make the transition pretty easy once I do. Thoughts?Import maps always worked and will work. The difference with JSR is that each library can have their own import map too.
Not sure if I understand the question, but will reply anyway :) Annoyingly, JSR import paths look very different to deno.land style plain URL imports, in that they start different and end different.
This means you can't just set up a prefix like "@std" in the import map, and easily switch between JSR and something else by editing the import map only. So, you need to set up and map full aliases for each possible import to be able to switch repositories or use local filesystem copy, without touching the actual import statements in code.