deps.ts is currently the most common way, however new projects like fresh use import maps. the problem with importmaps is they are not composable, as such, using an importmap for a library is usually bad as said importmap is not picked up and used, so the end-user would have to add their own importmap with entries compatible for the library (this is what fresh does: it generates an importmap with entries it needs). due to this problem, deps.ts is the most common solution, however I do hope that composability issue with importmaps will change.
It could be nice to have import-maps composability. However, I don't think it is planned because browsers' import-maps are not composable. I dislike the deps.ts concept. It is one of the main reason I did not switch to Deno yet.
Re:Big changes ahead for Deno
by qbasic_forever on Monday August 15, 2022 @05:24PM
(#32475579)
IMHO it's a feature and not a bug that if you import a dependency you also have to carefully review and approve (or add) its dependencies to your application. The entire reason node is a mess of supply chain issues and problems, and is almost like nuclear waste in some professional orgs (i.e. impossible to use because of unclear and unknown licensing concerns, ownership, etc. across thousands of dependencies) is from the ease at which long and complex dependency chains are pulled into a single npm install.
I would like to see import_maps managed with nix. Deno "lacking" a package manager seems like a great opportunity for content addressable web bundles.
Re:Big changes ahead for Deno
by RaitoBezarius on Monday August 15, 2022 @07:14PM
(#32476799)
Ha, that's something I was working on and I had a little proof of concept with Aleph.
I wonder if Go's approach to version resolution would work here?
Re:Big changes ahead for Deno
by yesbabyyes on Monday August 15, 2022 @09:01AM
(#32469131)
I've only built a few toy apps with Deno. I use import maps and consider them the canonical solution.
When contemplating how I might do it, I came up with centralised reexport, a file deps.ts containing:
This would basically stand in for the dependencies object in package.json.So then I looked up the docs and found https://deno.land/manual/linking_to_external_code#it-seems-u... and was amused to find the same solution, even down to the file name “deps.ts”!
Is this how people tend to work with Deno?
I see it also supports import maps, https://deno.land/manual/linking_to_external_code/import_map..., which could readily solve the problem too. Do people use that?