#Package manager for Deno ??

50 messages · Page 1 of 1 (latest)

knotty moth
#

(copied from my github issues) 👋 Perhaps issues may not be the best place for this question, sorry, but I am interested in creating a program that manages the 'deps' directory, where I keep all the module imports for my Deno applications. Just as there is no dreaded 'node_modules,' 'deps' would consist of just a simple list like a 'package.json' paired with 'npm || yarn init' 🤔

I would like to have an open dialogue regarding this type of handling for project automation, which is quite straightforward due to the structure we have in Deno. 🚀 🦕

earnest pollen
#

I don’t understand the npm || yarn init part of this

knotty moth
#

sorry, what I meant is the equivalent of a tool that manages module imports(only) automatically in Deno projects, and I'm looking to implement concepts similar to Node's NPM, Python's Pip, or Rust's Cargo
particularly I implement a part of my codes just to import modules

remote latch
#

Just use import or import().

rough steppe
#

Not sure what advantage your idea has over an import map or deps.ts

burnt mesa
sudden raft
#

Is this Deno 2.0 built in package manager is an implementation of Trex ?
Or we will have to use Deno CLI like "deno install nest" ?

burnt mesa
slow aspen
#

Simple answer, deno should never have a package manager.

waxen edge
#

What would be nice is a set of fns (and maybe cli tool) to manipulate import statements throughout a codebase and also the import map. So you could update versions easily, may do wholesale replacements of urls (eg. switch from a deno.land/x to a rawgithub url to test out an unreleased feature), the evils of deps.ts could be avoided then. So, I'd suggest that what Deno needs, is not so much a 'package manager' in the npm sense, but an 'import manager'.

#

And obviously use of such a tool is entirely optional (unlike npm).

burnt mesa
waxen edge
#

Interesting, I'd not seen dep before, looks like it provides similar functionality to https://deno.land/x/trex, although a bit unmaintained.

round sable
#

theres also esm.sh for npm modules

waxen edge
#

i'm thinking we need some tooling for maintaining the imports throughout the codebase (of library modules, where an import map isn't practical), so we can easily use and update absolute URLs without the baggage that deps.ts and mod.ts brings. I wrote a blog about this... https://jollytoad.deno.dev/blog/dependency_hell

earnest pollen
burnt mesa
# earnest pollen > This leads to consumers of your library depending on everything in your librar...

I mean I agree with him it is inefficient.

Imagine 15 tools that all use 1 function from lodash. Sure tree shaking is a thing, but it's not without problems and without it we end up with 15 lodashes. Now imagine 15 libraries that import one function from lodash directly; we just get 15 individual files instead of 15 lodashes (which is like a 50x improvement).

Lots of deno packages work on the browser too, including lots of the standard library. Once we've got a project with a deep dependency tree bundling all that extra code has a ton of cost and it's not easy to fix at that point.

earnest pollen
#

@burnt mesa i don't know how deno handles all of this, but pnpm has pretty much solved this for node.js using symlinking. 🤷‍♂️ i think in reality it's never really been an issue?

#

well i shouldn't say never been an issue, but if anything, tree-shaking has become way easier than it was before

waxen edge
#

pnpm, symlinking, treeshaking - these are all work arounds for a badly designed (although I think it more evolved than was designed) package/dependency system. If you get the design right from the begining, and the Deno ecosystem very much has the opportunity to do that, then you don't need these work-arounds. It's a pretty simple design, just import exactly what you need, and have libraries that just export small units. Yes, it may not be as convenient to import as single mod.ts but this is an issue of developer tooling, not build or runtime tooling. I split a lot of my projects into separate libraries, and I have to maintain URLs across many files in my codebase, and yes it's a little bit of a pain, atm I have to find/replace these to upgrade, but I find it a lot easier to understand my code because only the things I really need are in play, deno.lock suddenly becomes quite useful as a tool to see what is being used, at what versions etc. So, as far as packaging/import management goes, what I want (and do intend to implement when I have time), is a small tool to simplify the find/replace a little bit.

placid wedge
#

When we start to copy/paste url/code into a project (like: https://deno.land/std...) I see a bad design, I wish to see something like: deno add loadash (and deno rm loadash) or deno add npm:loadash without node_modules giant directory 🙂
The only good part in npm is when you don't need internet if everyhitng is cached in your system, well I prefer pnpm btw.

round sable
earnest pollen
round sable
#

one thing I wish deno had was a warning message for imports that redirect, to prevent people from using implicit versions and an option for fmt to change redirects tho

#

bc I hate when I import a library and it imports something else with an implicit version and incorrectly uses it because it expected an older version

earnest pollen
#

Part of me thinks that these suggestions are from developers who barely started using Deno, maybe they legit feel like npm is missing. If so, I can low key understand the sentiment.

burnt mesa
round sable
# 
// my code
import { .. } from 'https://deno.land/x/[email protected]/mod.ts"

// module/mod.ts
//                         Implicit latest version v
import { func } from 'https://deno.land/x/dependency/mod.ts'
//        ^ this function is deprecated, moved or removed in the latest version
//          but the import expected a version that has this function
placid wedge
waxen edge
#

I can't believe I've only just discovered https://github.com/hayd/deno-udd ... why aren't the Deno team considering this approach, maybe just adopt this tool into denoland? Combines the comfort of having explicit URLs and convenience of updating them. Tools like this would be a much better approach than a new url scheme, deno:, jsr: or whatever, IMHO.

GitHub
GitHub - hayd/deno-udd: Update Deno Dependencies - update dependenc...

Update Deno Dependencies - update dependency urls to their latest published versions - GitHub - hayd/deno-udd: Update Deno Dependencies - update dependency urls to their latest published versions

wispy crypt
soft shore
#

udd might be the most popular but looks somewhat dead today

indigo goblet
#

I think it would be nice if Denoparty_deno has create command such as
deno create fresh@latest

It's really nice and helpful for developer experiences hooray_deno .

soft shore
#

that's like turning deno more and more into npm/node

#

aka. a total nightmare

#

also why would you need smth like that?!

earnest pollen
#

Agreed. How often do you actually create new Fresh projects for that to be worthwhile

soft shore
#

it'd just be an alias for calling deno run ...

#

xd

earnest pollen
#

Yeah pretty much

placid wedge
indigo goblet
#

// By default Deno playful_deno use deno.land/x for packages registry.
deno add react react-dom // looking react and react-dom in deno.land/x and downloading if It's not appear in Deno local's library. but if it's already had package 'react' and 'react-dom' in local's it's will linked to downloaded package in local's deno developer machince.
deno update // update package that's shown in import_map.json or imports key in deno.json
deno remove react react-dom // remove package named 'react' and 'react-dom' in import_map.json or deno.json
deno delete react // to remove package named 'react' in import_map.json and also delete in Deno local's library.

// And user can also use other registry such as esm.sh, skypack, etc. by Using deno pkg <registry> to set registry source where developer would like to used. hooray_deno
deno pkg esm // to use esm.sh as registry for deno add, update, remove commands.
deno pkg skypack // to use skypack as registry for deno add, update, remove commands.
deno pkg npm // to use npm as registry for deno add, update, remove commands.
deno pkg x // to use deno.land/x as registry for deno add, update, remove commands. (back to default registry)
deno pkg list // listing all package currently downloaded on developer's Deno local's library. show name, source(esm.sh, skypack, etc.) and version or more?

// By this way it's can extended developing experinces in Deno party_deno to more widely. and improve productivity and take adventage of
millions of cdn library from many user's known registry can integrate with deno developer. made Deno playful_deno more easy and flexible to use.

// ref.
https://deno.land/x/esm@v134#using-cli-script

indigo goblet
soft shore
soft shore
#

if you got any ideas for new features, please join the discord and share them with me (:

waxen edge
#

@soft shore are you familiar with https://jspm.org/, how does den.ooo differ from that? I know jspm doesn't focus on Deno, but it's definitely something they'd like to improve support for.

soft shore
#

den.ooo is quite different.

a) it only resolves import maps for deno code
b) e.g. you have a import * as esbuild from 'esbuild', that'll be rewritten to smth like import * as esbuild from 'https://deno.land/x/[email protected]/mod.js' (according to the imports map in your deno.json file)