Actually, I can’t think of a single issue that npm doesn’t also have.

Possible issues:

- trust

Not an issue since if you trust an author’s packages on npmjs you should also trust them from unpkg, github, etc... (Aka there is no trust in npm land except trust in the author)

- Versioning

Put the version in the url instead of some json, same difference.

- Lack of ^ for automatic upgrades

That’s a feature. Avoids the need for lock files.

- Repetitive

Have a dependencies.ts to group external imports, same thing as package.json

Any other issues?

Dependencies, especially for dynamic imports?

Going from what he said about packaging, every program/module is compiled into a single file, including dependencies.

Wouldn't that lead to even more bloat than what he regretted in the talk?

Runtime dependencies is what he is trying to get ready of.

You will always have built time dependencies with npm/yarn.

I'm not a huge NodeJS developer, but have done enough (and other development) to think this is not a good solution to the packaging/dependency problem.

My experience with npm issues were usually that some dependency had its own build process.

There are so many inconsistencies in how JS libraries are packaged and downloaded. I think scripting in general leaves the whole dependency thing out in the wind.

Now. If we could turn packages into testable objects, that would be cool.

Well, packages are testable. You can test the api of a package today. Having people write said tests is the tough part.

Did you mean to say something else?

I meant more like a binary compiled object. So many libraries have a highly varied set of folders and files. It’s just messy.

His arguments for it seemed reasonable - would love to hear your criticisms

What the others say.

And also, golang tried no centralized package management by using git repo. It didn't end with people go getting from moving masters. Of course they did.

And in an area of finally accepting lock files, do you really want to go back in middle age ? Lock files are not a constraint. They are a god saver. You want lock files. You don't want to have either vague dependencies or pin pointed ones. You need both to stay sane.

And of course somebody will do something dynamic that will open a security issue.

And of course typo squatting is going to be so much easier.

And removing a bad lib ? From npm you signal the admin. When it's on it's own domain ? Good luck.

And then searching for libs is going to be fun. And naming, naming will be amazing.

And having a quick glance at the dependency of a lib ? So much fun.

And wait for the search/replace in the code that will change your entire run time by mistake.

And no possible alternative package manager. Hope their dependency resolver never sucks cause you will be stuck till you can install the next node... if they ever fix it.

Ah, and the git blames to see what dependencies have changed are going to be just peachy.

Oh, and your juniors copy/pasting code from the net is going to get extra crispy.

But wait, running the code on conditional imports means your project may install something at ANY moment in its life cycle. And could be changed by somebody editing the code by mistake without really asking to change a depandancy. You know, like a ctrl + D on "0.1" to replace all those floats quickly.

Also cool URLs don't change. Until they do. Tiny URLS dependencies are going to be hilarious.

I could go on and on and on and on...

I can't understand how you can be intelligent enough to code freaking node JS and not see THAT elephant in the doll room.

You are imagining the worst possible execution of these ideas. Nobody is proposing that you should start using libraries that pull in code from random domains, unless you have some specific need to. Whitelisting sources is such an obvious step, given the security focus, that you should really have applied the https://en.wikipedia.org/wiki/Principle_of_charity in your speculation.

No one proposed to make spaghetti code with "goto".

Yet we did. And we replaced it with "if" or"while", to avoid repeating history.

This is a prophecy: this dep managing concept, if kept in this form, will cause something terrible. It will.

Good luck.

> golang tried no centralized package management by using git repo. It didn't end well.

What? There's no fundamental problem with it. It will continue. What do you mean?

I like go as a language, but its lack of package management is the single reason I no longer use it.

Go has had primitive package management for 5+ years, and official package management (in some form or another) for a year.

The go team recognise there's a fundamental problem with it, otherwise they wouldn't have created dep and vgo [1]

[1] https://github.com/golang/go/issues/24301

`dep` and `vgo` both continue to use URLs as import paths. They optionally provide other means of fetching code.

Not OP, but a couple guesses off the top of my head:

* It becomes a more painful process to upgrade dependencies (have to find/replace across your codebase).

* Many versions of the same library get pulled in. If you depend on [email protected] and a dependency of yours depends on [email protected], that's twice the dependency size as compared to both just using 1.5.4. This matters more in the case of web app bundle size though than running local programs.

You could have an entry file for your dependencies (let's say dependencies.ts) and reexport everything from there. When you have to update, you only have to upgrade it in the entry file and you can avoid multiple versions.

Hm, how about we call that file package.json?

How about we link them to modules downloaded onto local file system instead, just in case of network issues.

How about a cli tool to cache and build those modules/native extensions all at once? We could call that Deno Package Manager.

But this is exactly the way the Web works. Right? And that platform seems to have done alright for itself.

For libraries or professional projects, ship your dependencies or use a build system. But for one-off projects, being able to pull in a utility library without needing any tool but the interpreter you're using or some extra build step seems like a big win.

The entire world moved out of inline dependencies in the HTML page to a package managers. We invented bower or npm __because__ of it.

We invented bower or NPM because people thought it was a good idea to have 20MB of JavaScript on a page and 19MB of it written by third parties. Generally speaking, this turns out to have been a mistake.

What if it said import { test } from "https://npmjs.com/[email protected]/testing.ts" ?

Care to elaborate?

I did. But I was not expected to have to. It's quite unsettling.