This is package.json with extra steps. And yet, people using Deno are so against package management.

You can use import maps too: https://deno.land/manual/linking_to_external_code/import_map...

Deno's philosophy is to be aligned with web browser standards. I suspect import maps will be the path forward for most projects as it's what browsers will or are supporting today too.

> You can use import maps too

Again looks like package.json with many manual steps in between (where to get those import maps is the first question).

Also, apparently non-composable etc. https://news.ycombinator.com/item?id=32469280

> Deno's philosophy is to be aligned with web browser standards.

And yet they want to be able to run npm packages...

Package.json is a mess, it combines a million different concerns like project metadata, dev environment, scripts, and random key/value pairs along with all the dependency information. It's a node and npm specific configuration that ballooned into a dumping ground for metadata. There's no reason to keep it around in a new runtime.

You create the import map by figuring out what dependencies you want to use and crafting it and your code to reference them. You can do anything--you can import five different versions of the same library but under different names if you want. This was not something even possible with node and npm. You can make it as simple or as complex as your needs require. For most people they'll keep it simple and drop a few import urls directly in their source, never even needing to touch a tool or other file to worry about dependencies.

They're giving users what they want, an ability to run packages which haven't been ported to work with deno yet. The blog post explicitly makes this clear. This is not some grand conspiracy like so many replies seem to be trying to imply.

> You create the import map by figuring out what dependencies you want to use and crafting it

Ah yes. Truly the same amount of effort as package.json.

How exactly do you figure out all dependencies (including transitive ones) and "craft" that?

Edit TIL you can install as many versions under different names as you want with npm: https://medium.com/weekly-webtips/how-to-install-multiple-ve...

> This is not some grand conspiracy like so many replies seem to be trying to imply.

There's no conspiracy. All the awkward workarounds with tedious manual steps to recreate a package.json "dependencies" field are frankly laughable. Deno should bite the bullet and automate this since they already have the dependency resolution built in. No need to "craft" anything.

Seriously, no idea why anyone things this is a better option. Seems like more work, and if two packages export things with the same name you have to use aliases. Also, seems like this could get REALLY messy on large projects.

I LOVE TypeScript, and was so excited about Deno when I first saw it, but the lack of package.json "feature" is a huge turn off for me. I sometimes feel like I'm the only person that has no problem with package.json. I think it works great.

Haven't used deno but I assume the standard `export * as asserts from "https://deno.land/std@0.152.0/testing/asserts.ts";` will work, which is the same effort as a package.json and does not create any identifier conflicts.

> which is the same effort as a package.json

Apart from the fact that you don't create package.json by writing "export * from" by hand.