6
AleCx04
5y

!rant - well maybe

I really wonder what is going to be the end product concerning Deno and TypeScript when it deals to managing dependencines. Thus far the general idea is to have a deps.ts file for which the dependencies required are fetched through a url, cached into the project and then imported from that file onwards.
This seems interesting to me, and I would venture to say that it eliminates some of the pain points from running Node applications, we all know about the dread caused by overly large node_modules folders, but would y'all say this is the right approach? rather than stopping people from generating a large pool of dependencies, it seems that the issue would continue to persist, but it would just come from the internet during runtime rather than from living in the file system of the application.

Either way, I still remain a big fan of Ryan Dahl and his creations and can't wait to see Deno stable enough to test out on a couple of projects.

Comments
  • 1
    It's a little Frankenstein, but it's heads and tails past what node has right now. I don't see most people in the existing ecosystem adopting it, but it can become a viable, safe alternative.

    On deps, deno allows a local flag copy, and you can do a system intermediary management of your deps via s3 or any flat url addressable location. I kind of prefer it, less magic.

    I'm glad they produced it ☺️
  • 1
    I think the idea is it will cache the dependencies centrally somewhere. Also there's a standard library apparently. The lack of that is a huge contributing factor to the node_modules problem.

    Still not sure how I feel about it. Rando urls for dependencies sounds icky to me. I see the upsides but I also see security issues. Deno is one fake tutorial away from ruining a lot of beginner's days
Add Comment