Discussion: About dependency management

[acathur]

There're some discussions about dependency management. I think when we people started to use deno to build complex programs, a dependency manager is desired. Removing node_modules from the project folder is a brilliant revolutionary design, but I'm not sure whether the package.json file also should be deprecated. Currently, people use a deps.ts file or import_map.json to manage the external modules, it seems like a central specification file is necessary, and module versioning is another important thing in production environment. In my opinion, manage these modules manually is definitely a terrible development experience, so I built this stuff dep, a simple cli to manage project dependencies, but unfortunately, I used a file called pkg.json (maybe will change to spec.json) to describe the information of the project, and a dependencies map like package.json do, the program will automatically generate or update a import map after adding external modules, so you can import any module with a relative URL. Also I kept all the features below:

• keep no packages
• keep ES modules semantics
• keep file extension
• keep remote URL imports (Source URLs in import map, relative URLs in scripts)

I just want to know if this is an acceptable solution? What are your opinions on this?

[nayeemrmn]

Any discussion about first party package management should be taken to #47. But if you'd just like to showcase and gather opinions on your project, a better place to do so would be the Discord https://discord.gg/deno.

[acathur]

Thank you @nayeemrmn, I got it, but I really want to know what the attitude of the core members is, @ry was against to the centralized repositories and even a package.json file, but now there is a third party modules page on the deno official site, I think it's good for building the ecosystem around deno. Module contributors need a file to describe the info of their projects, and package.json is only a specification file for the module owners, deno or the dependency manager will never need to lookup or download any dependency by package.json.

[nayeemrmn]

Module contributors need a file to describe the info of their projects, and package.json is only a specification file for the module owners, deno or the dependency manager will never need to lookup or download any dependency by package.json.

@acathur What are you proposing, then? If it's just for people to describe their projects and Deno won't need to look it up, how is this an actionable issue? Your title is as vague as it could possibly be and the description is, in clear terms, simply asking for feedback on your third party project. Please edit them.

[acathur]

@nayeemrmn Sorry for my English, I'm not a native speaker, maybe made some mistakes in my sentences. I am not trying to introduce my project or asking feedback here, I mean I'm worrying about this solution is disapproved by the deno team, or do you have some guidelines or plans or suggestions on dependency management tool?

[balupton]

I've created make-deno-edition to make npm packages written in typescript compatible with deno - is working on badges - usage proof of this here https://repl.it/@balupton/badges-deno - has been used now to make 32 node packages compatible with deno - you can use project to automatically generate the readme instructions for the deno edition - and can use boundation to automatically scaffold your projects to automate the entire process - start-of-week is an example where different entries are used for node, deno, and web browsers

[ChristianGrete]

@acathur I do think that this is an acceptable approach for a third party dependency management tool. And I do like your approach. Also, I don’t think, that this should be part of Deno itself... As you’ve pointed out, the major problem with URL imports is that they would have to be maintained all over the place. With import maps, Deno already has a solution for that. The only difference is, that your tool automates and standardizes the import map creation and also creates a pkg.json file that is required to run the dep start command but doesn’t seem to make sense in any other way.

[ebebbington]

There's also nest and dmm that manage dependencies, without any files needed for the user to have - simple read and write to deps.ts

The beauty of Deno, is it takes very, very little to manage dependencies - though it can be problematic when a 3rd party module uses other 3rd party dependencies

[nayeemrmn]

This can be closed as a duplicate of #47.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lucacasonato]

Nothing actionable here. Closing