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.
> 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.
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...